More beginner's verilog questions

[Reza Naima]

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

 

[Rob]

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

 

[Art Stamness]

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

 

[Reza Naima]

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

 

[Reza Naima]

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

 

[johnp]

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

 

[Andy Peters]

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

 

[Reza Naima]

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

 

[Reza Naima]

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

 

[Mike Treseler]

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

 

[Reza Naima]

With regards to the clock - the design has a counter, but all the
counter does is count the number of pulses that come in. I can't see
how a seperate clock would be required for a counter.

Also, are there some sort of standars for using a clock? Can you flag
an input as being a clock such that the synthesizer would do something
special/different with it? Or is it just a input that you deal with in
your own way?

Thnx,
Reza

 

[Rob]

I have used the following book and it has been very helpful.

Modeling, Synthesis, and Rapid Prototyping with the VERILOG (TM) HDL
by Michael D. Ciletti

"Reza Naima" <google@reza.net> wrote in message
news:1135064071.868137.197590@z14g2000cwz.googlegroups.com...

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

 

[santosh]

Reza,
Well,What is it that you have thought of the RTL of the counter you
would like to code?

 

[Reza Naima]

Santosh -

I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :

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

reg [4:0] index;
reg [31:0] out;

always @(posedge counter_increment or posedge reset) begin
if (!reset)
index <= index + 1;
else
index <= 5'b00000;
end

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

endmodule

I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....

ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.


reza

 

[Jason Rosinski]

Hmm, right now I don't see what it's complaining about, since the asynchronous reset is active
high. My suggestion would be to rearrange the blocks a little. Try something like:

always @(posedge counter_increment or posedge reset) begin
if (reset)
index <= 5'b00000;
else
index <= index + 1;
end


Am I missing something obviously wrong with the sensitivity list here? Or is it just a problem
with the synthesiser?


Reza Naima wrote:

Santosh -

I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :

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

reg [4:0] index;
reg [31:0] out;

always @(posedge counter_increment or posedge reset) begin
if (!reset)
index <= index + 1;
else
index <= 5'b00000;
end

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

endmodule

I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....

ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.


reza

 

[johnp]

I believe that you need to give XST hints to infer logic that maps onto
the architecture. I was at a Xilinx presentation where they used the
RSE letters to denote the order of priority that operations need to
be entered in order to map onto the flip-flop efficietnly:
always @(posedge clk)
if (Reset)
// reset stuff 1st
else if (Set)
// set stuff second
else if (Enable)
// enabled logic last

This is because of the priority of the Reset/Set/Enable functions built
into
the flip-flops.

It could be that the original code fragment confuses the code
generator.

John P

 

[Chris F Clark]

See the things in you design which are always @ (posedge xyzzy) begin
foo <= bar, the xyzzy is a clock, even if you don't call it clock.
The foo <= bar is an "edge clocked" flip-flop/register. Things happen
on the posedge of the xyzzy clock. If the clock is "periodic" hooked
up to some kind of oscillator, then it is obvious that it is a
clock. However, even if the clock is not periodic, it is still a clock
and it tells "when" something happens.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

 

[Andy Peters]

Reza Naima wrote:

Santosh -

I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :

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

reg [4:0] index;
reg [31:0] out;

always @(posedge counter_increment or posedge reset) begin
if (!reset)
index <= index + 1;
else
index <= 5'b00000;
end

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

endmodule

I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....

THINK HARDWARE. What sort of logic will this code create?

Answer: some flip-flops. And flip-flops require a clock to change
state. In the example you give above, the signal counter_increment is
used as the flops' clock input. (You might want to read the synthesis
tool manual to learn why.)

The other gotcha that you probably don't realize is that the signal
enable will ALSO be used as a clock for the flips in the signal out.
On every rising edge of enable, the value of in will be clocked into
out. Again, a simple perusal of the synthesis tool manual will explain
why.

ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.

That's because your code doesn't follow the templates for synthesizable
flip-flops. Specifically, you can't do anything "more complex" than
assigning constants (the reset values) to the flops in the if (reset
....) clause.

The other reason for the error is that the asynchronous reset has
priority over the synchronous update. You've coded it such that the
synchronous update has the higher priority.

-a

 

[Andy Peters]

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.

Not knowing the details of your design makes it a bit difficult to tell
whether a global clock is necessary, but the reason for synchronous
design (the entire design clocked by a global clock) is that is
simplifes timing analysis and helps to ensure that the design will
actually work.

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.

I'm actually talking about Digital Electronics Design 101 -- back to
basics.

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.

Can the project wait for you to develop the skills to ensure that it is
successful?

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.

The synthesizers _are_ very smart, but you don't want them to be too
smart. The tools are capable of generating logic that may be
functionally correct, but may be too large to fit in a chip, or may not
run at the required speed, or both. Writing concise descriptions
allows the tools to produce a more optimal result.

-a

 

[Ray Andraka]

I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....

ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.


reza

Asynchronous logic does not belong in FPGAs. They are not designed for
it and the tools don't support it (especially static timing analysis).
Wires in FPGAs have delays associated with them that are on the same
order of magnitude as the delays through the logic primitives.

While your ripple count structure is a viable clock structure, it does
have some things you need to watch out for: 1), the outputs do not
update all at once, rather the lsb changes, then the next bit and so on,
hence the name ripple count. As the counter gets wider, the maximum
count speed at which you can extract a usable count diminishes (but note
that if you don't need the lower order bits, this can be faster than a
synchronous counter). 2) The input is sensitive to glitches on the
input signal. Mechanical switches will 'bounce', so you'll need to
include logic to filter out the multiple switch closures that happen
every time you actuate the switch.

Timing analysis (studying the time delays in your circuit to make sure
that it will run as fast as you need it to and that it won't break
because of signals getting somewhere either too fast or too late) is
much easier in a synchronous design (one where a common clock is
distributed to all the flip-flops in the design) because each timing
path is punctuated by the flip-flops...you only need to evaluate the
propagation delay time from flip-flop to flip-flop. In an async system,
you need to take into account the propagation delays on all paths from
the input to the output to make sure you don't have race conditions that
would upset the proper operation of your circuit. Also, synchronous
design eliminates the dynamic hazards you need to deal with in an async
design.

Even asynchronous resets are bad for FPGA design. First, the tools
don't trace the delay paths for the asynchronous reset through the
flip-flop, so you could wind up with timing hazards and not be aware of
it. Second, there are start up hazards which have been discussed ad
nauseum here in the past. If you really need an async behavior, for
whatever reason, just connect the external async reset to the PROGRAM
pin on the FPGA.