FPGARelated.com
Forums

More beginner's verilog questions

Started by Reza Naima December 19, 2005
After I found out that I couldn't syntesize a lot of the verilog code (
http://awlnk.com/?aRts ), I had to redesign how I was going to
implement this design.  I'm going for something significantly easier,
though I'm breaking it up into more modular parts.  I'm getting all
sorts of errors from all over the place (using both silos synthesizer
and the xilinx webpack).   The code is very simple - I want to be able
to set one of 32 pins as high, low, or high impedence using a minimal
number of input pins.  The design I came up with so far incorporates a
counter latch/demux.  I'm not sure how to implement the highimpedence
functionalty of the output, so I've ignored it for now (though I would
love some input).  Here's the code so far -- any help would be greatly
appreciated!! :

module counter32(in,reset,out);
    input [0:0] in;
    input reset;
    output [4:0] out;

	always @(posedge in) begin  /* i've seen sample code include reset
here, dont know why though */
		if (!reset)
			out = out + 1;
	end

	always @(posedge reset)
		out = 5'b00000;

endmodule

module latch32(in,out,enable,signal);
    input [5:0] in;
    output [31:0] out;
    input enable;
    input signal;
    integer N;

    always @(posedge enable)
    	out[in] = signal;

endmodule


module counterLatch32(in,reset,enable,signal,out);
    input [0:0] in;
    input [0:0] reset;
    input [0:0] enable;
    input [0:0] signal;
    output [31:0] out;

    wire [4:0] select;
    reg [31:0] out;

    module counter32(in, reset, select);
    module latch32(select, out, enable, signal);

endmodule

I'd pick up any book on Verilog and read the first 2-3 chapters.  This will 
solve a majority of your problems.  You're making fundamental mistakes with 
the shown code.

"Reza Naima" <google@reza.net> wrote in message 
news:1135039228.101043.151430@o13g2000cwo.googlegroups.com...
> After I found out that I couldn't syntesize a lot of the verilog code ( > http://awlnk.com/?aRts ), I had to redesign how I was going to > implement this design. I'm going for something significantly easier, > though I'm breaking it up into more modular parts. I'm getting all > sorts of errors from all over the place (using both silos synthesizer > and the xilinx webpack). The code is very simple - I want to be able > to set one of 32 pins as high, low, or high impedence using a minimal > number of input pins. The design I came up with so far incorporates a > counter latch/demux. I'm not sure how to implement the highimpedence > functionalty of the output, so I've ignored it for now (though I would > love some input). Here's the code so far -- any help would be greatly > appreciated!! : > > module counter32(in,reset,out); > input [0:0] in; > input reset; > output [4:0] out; > > always @(posedge in) begin /* i've seen sample code include reset > here, dont know why though */ > if (!reset) > out = out + 1; > end > > always @(posedge reset) > out = 5'b00000; > > endmodule > > module latch32(in,out,enable,signal); > input [5:0] in; > output [31:0] out; > input enable; > input signal; > integer N; > > always @(posedge enable) > out[in] = signal; > > endmodule > > > module counterLatch32(in,reset,enable,signal,out); > input [0:0] in; > input [0:0] reset; > input [0:0] enable; > input [0:0] signal; > output [31:0] out; > > wire [4:0] select; > reg [31:0] out; > > module counter32(in, reset, select); > module latch32(select, out, enable, signal); > > endmodule >
I will agree with Rob, you need a book. Clearly this is a homework
problem . . but you did a good job to start. So here are some pointers
that should help.

Generally :

1. Name your ports and your I/O's, something that means something.
"in", "out", "signal" are not very helpful. All these devices should
have an input called "clk".
2. Whenever assigning a sequential element ( flop / latch ) using a
reg, use the '<=' non-blocking assignment operator in verilog. This
will save you many headaches in the future.
3. [0:0] is unecessary, as an unsized input, output, reg or wire is
always 1 bit or [0:0].

Specifically:
1. (counter32) Don't assign a value (out) from two different
always-blocks. This is a synchronous version of the same flop, with an
enable ( en ) , and a clear ( in place of reset ) .

always @(posedge clk)
  if ( !clr)
    out <= (en) ? out + 1 : out  ;
  else
    out <= 'b0 ;

2. Latches are troublesome and usually not preferred in FPGA design, if
you can use a flop. But if ( god forbid ) you need one. Here is how to
code it :

always (clk or d)
  if ( clk ) q <= d ;

This is a single bit flop. Who's value is set on the output whenever
any value changes and the clock is high ( the definition of a latch ) .


3. (counterLatch32) You are confusing module declaration with module
instantiation. A declaration using the word "module" followed by the
name of a module, followed by all the stuff in a module, followed by
the word "endmodule". What you need to do is make an instance of a
block so it might look like this :

counter32 count_a ( .clk(clk), .en(en), .reset(reset), .out(out) ) ;

This will instance a counter32 module and connect its inputs and
outputs to wires to wires of the same name in the parents module scope.
The instance name will be count_a.

I hope this all makes sense. I am sure you can find some good online
FAQ's about verilog. Please look up those for further info. Best way to
learn is by just copying someone else. 

-Art

I bought a book a book recommended by one of the application engineers
at a reseller of Xilinx  (Verilog HDL), and it described verilog very
well.  But it didn't distinguish between what was used for simulation
and what is synthesizeable.  So my first bit of code (if you look at
the link) worked fine on the simulator, but it relied heavily on
constructs that could not be synthesized.  I then asked for
recommendations on books, and was told that there were no good ones.
Hence I'm hoping I can get some pointers to reference code, or some
help debugging the code I wrote.  

Thnx,
Reza

Art!

Thanks so much for the pointers.  I've gone through the literature (the
book I have), but it's all about syntax and nothing about practical
applicaiton.  A few quesitons however :

- why do you need a clk?  Why does anything need a clock?  If I can
synthesize a device which is a set of nested gates (i.e. an 'AND' gate)
which perform logic, where does the clock come in?
- why  out <= (en) ? out + 1 : out  ;  ?  Why not  "out <= (en) ? 1 :
out"  Though I'm more interested in "out[index] <= (en) ? in :
out[index]" -- can I do that?  i.e the counter determines the index,
and the enable alows me to latch the value.
- is it possible to have the input (in) above be tri-state, such that I
can latch 0, 1, Z? (i think Z is high-impedence)


Thanks again - I'll start playing with some of the suggested changes
and see how far I can get.  
Reza

Reza -

Most designs use a clock becuase they are synchronous designs. Current
methodologies favor this design style for many reasons, too many to go
into here.  In a synchronous system, all logic is clocked by some
(small)
number of system clocks.  This makes timing analysis easier and avoids
a lot of potential bugs.

You should take a look at some real life examples of Verilog code to
see
how it is written in the real world.  There are lots of sources to look
at
on the web, take a look at some of the simpler designs at opencores.org

One thing to remember - some of the Verilog language can't be
synthesized.
When you're coding something, try to imagine what the hardware would
look like.  For example, the "wait()" construct is not synthesizable.
Why?
Could you imagine harware to implement something like wait()?

Good Luck!

John Providenza

Reza Naima wrote:

> - why do you need a clk? Why does anything need a clock?
I suggest you take a course on digital electronics design. If you're asking "why do you need a clock," you've got a lot of ground to cover before you start trying to design with Verilog. -a
I think John answered the question by stating that the clock is useful
for syncronization and debugging, but ultimatly it seems as if I am
correct in my assertion that a clock is not explicitly required.

Digital electronics design seems a bit vague - can you be a bit more
specific?  There are verilog-specific courses offered in my program
(I'm in graduate school) - but I think it's an overkill for my needs.

Alas, the current project I'm working can't wait for me to take more
classes.  Either this is implemented in a CPLD or else I'll have to use
discrete components.  I'm going to follow some of Art's suggestions and
see how far I can get.

I've also looked at some of the sample designs on opencores, and they
seem a bit too complex to learn from.  I'll look around for some other
simpler sample code.  One of the other problems with looking at sample
code is that a lot of it is minimally commented, and it's very hard to
figure out why people are implementing someting in one way vs. another
way.

With regards to a wait(), I figured the compiler/synthesizer would
generate some sort of clock/counter with some sort of comparator to
trigger the event.  I was hoping that the synthesizers were a bit
smarter than they seem to be.  

Thanks,
Reza

Oh, one other question regarding clocks.  By not using one, wouldn't
the device consume significantly lower power?  I still don't see an
advantage of having a clock in this design.  

Thnx,
reza

Reza Naima wrote:
> I think John answered the question by stating that the clock is useful > for syncronization and debugging, but ultimatly it seems as if I am > correct in my assertion that a clock is not explicitly required.
True if your design is 100% combinational without a single shifter or counter.
> Alas, the current project I'm working can't wait for me to take more > classes. Either this is implemented in a CPLD or else I'll have to use > discrete components.
In that case, consider schematic capture to enter your design: http://www.eecg.toronto.edu/~zvonko/AppendixB_quartus.pdf
> With regards to a wait(), I figured the compiler/synthesizer would > generate some sort of clock/counter with some sort of comparator to > trigger the event. I was hoping that the synthesizers were a bit > smarter than they seem to be.
That seems to be a common expectation. Unfortunately it is difficult to describe some sort of clock/counter without a clock input. -- Mike Treseler