More beginner's verilog questions

After I found out that I couldn't syntesize a lot of the verilog code (

formatting link
), 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

Reply to
Reza Naima
Loading thread data ...

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.

Reply to
Rob

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 '
Reply to
Art Stamness

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

Reply to
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

Reply to
Reza Naima

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

Reply to
johnp

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

Reply to
Andy Peters

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

Reply to
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

Reply to
Reza Naima

True if your design is 100% combinational without a single shifter or counter.

In that case, consider schematic capture to enter your design:

formatting link

That seems to be a common expectation. Unfortunately it is difficult to describe some sort of clock/counter without a clock input.

-- Mike Treseler

Reply to
Mike Treseler

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

Reply to
Reza Naima

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

Reply to
Rob

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

Reply to
santosh

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

Reply to
Reza Naima

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 Based on the feedback, I rewrote the module so it looks like this (and

Reply to
Jason Rosinski

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

Reply to
johnp

See the things in you design which are always @ (posedge xyzzy) begin foo

Reply to
Chris F Clark

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.

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

Reply to
Andy Peters

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.

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

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

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

Reply to
Andy Peters

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.

Reply to
Ray Andraka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.