Systematic approach for Verilog implementation

[tnet]

Hello,

As I am a novice to Verilog/SystemVerilog, I am seeking for some guidance regarding writing Verilog logic from purely just a timing diagram. (You may have seen my other posts).

For example, if my goal is to implement a logical block that has X inputs and Y outputs for the DUT, and all I am given is a timing diagram that shows the behavior of the input and output signals and how they behave according to the supplied clock. What is the best way to tackle this problem from an engineering perspective?

Should I be considering to first simply layout the module with the inputs and outputs and see how the timing diagram behaves and try to implement the logic based off of that?

Or should I be first be treating this as a "state machine" and draw a systematic schematic of showing all the inputs and outputs, showing when they should go HIGH or LOW at their certain times? Are timing diagrams usually implemented in a state machine logical flow?

Was hoping to gain some knowledge and understanding from the people who are experienced writing Verilog logic based off of timing diagrams and was hoping to see your systematic approach of how it should be implemented as if I was an engineer. 

Thank You.

[xc6lx45]

Hi,

I'm sure there will be some long follow-up answers. I specialize in short answers, so here we go ?

Engineers are frighteningly unsystematic. What engineers are good at is cutting corners.

Either you're completely in over your head, or you are facing an easy problem. For easy problems, engineers do a quick sketch on a paper napkin (skip if no napkin is available) and start coding.

So what you need is the Verilog skills to write down a FSM. Essentially, it might look like this

reg [7:0] state = 8'd0
always @(posedge clk) begin
  switch (state)
	case 8'd0: if (something) then begin ... state <= 8'd1; end
	case 8'd1: if (something) then begin ... state <= 8'd2; end
  endcase
	// this must be at the bottom of the enclosing begin...end block
	if (synchronousReset) begin
		state <= 8'd0;	
		... set everything else to init values
	end
end

It might look completely different (matter of style) but avoid e.g. asynchronous reset as commonly found in pre-FPGA tutorials.

Then write down what you think it should do. Simulate. Figure out why it does something else. Rinse and repeat and also update your understanding of what you think it should do...

Oops. It wasn't that short.

[D@n]

@tnet,

Let me try to add to what @xc6lx45 just said.  I've seen several design processes.  The typical student design process is

This ends up quite confusing for the student.  What @xc6lx45 is recommending would look more like,

I've argued in the past that this approach only makes sense if you have a means of properly viewing what's going on within the FPGA.  If you have no way of viewing the logic within an FPGA, then I'll argue that should be your first task.  You can read about the problem that results when you don't have that ability here.

This process, however, will not work for ASIC flows.  (FPGA flows typically teach students the design methods that they'll get paid more for when working for ASIC companies ... )  In an ASIC flow, the design *must* work right the first time (if you want to keep your job).  There's a *HEAVY* dependence on simulation and so forth.  Broken designs aren't allowed by the boss to go to the next step.

My own design process has morphed a bit since I first wrote the article on this topic.  I've now picked up formal methods as a means of building designs, using the free and open source tool yosys with SymbiYosys as the driver.  With every new bug I find using them, I get hooked all the more.  As a result, my new development approach for something like this would be:

1. Scribble out some code
2. Add a property package, like the one for the wishbone bus.  (I also have packages for Avalon and AXI available for sale, at least until I blog about them and then they will be public)
3. Add some other ad-hoc assertions (or assumptions about inputs) based upon my own estimation of my code
4. Apply the formal tools
5. View the VCD waveform in gtkwave.  Compare it to the trace I'm trying to match.  Create a cover property once the tools stop producing failing traces.
6. Lather rinse repeat until the code matches
7. Create a simulation component for the hardware I am attempting to interact with
8. Create a design including this component, and test via simulation
9. At this point ... the yellow figure above now applies again.

You can read my ramblings on how this works here if you'd like.

Hopefully that helps, if not then I've just rambled on for longer than @xc6lx45!

Dan