Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Verilog clarification request

Status
Not open for further replies.

uglyduck

Junior Member level 2
Joined
Oct 31, 2005
Messages
23
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,281
Activity points
1,613
pause verilog

Hello all,
Since I'm relatively new to Verilog I would like to ask two questions:

1. About " `timescale " directive: how this directive affects modules ? For the testbenches I know that for example " `timescale 100ns / 1ps " means that 1 time unit = 100ns (i.e. working at 10MHz) with simulator precision of 1ps. Am I wrong ? Ok, but how this directive affects modules ? What if the testbench have one " `timescale " directive and module have different ?

2. I started to implement just a simple thing as a Delay module for Xilinx CPLD XC9572. This module have two inputs - IN, CLOCK and one output - READY. It should work as follows - if IN changes (new input) an internal counter variable (reg type) is loaded with the value of IN. The counter starts counting immediately down to 0. If counter reaches 0, than READY becomes 1, otherwise READY is 0, meaning that the circuit is still working.
I have implemented this using counter and an internal variable of type reg that have the size of IN. It works fine, but I'm not sure that this is the correct way to implement a delay. And this circuit occupies more that 20% of the XC9572 resources ! I'm confused. What will happen if I just use a " #10 " for example, to delay the READY to become 1 after 10 time units ? Is it legal ? And I have no idea how the hardware will louk like in the point of view of the CPLD - I mean how this will be implemented (represented) by the logic in the CPLD.

Please, help me.
I'm very confused with these two problems.

Thank you very much
 

kgeorge123

Member level 1
Joined
Mar 23, 2005
Messages
34
Helped
8
Reputation
16
Reaction score
2
Trophy points
1,288
Activity points
1,763
constant-time up/down counters verilog

1. If you have different times scales for testbench and module usually testbench will take the priority and your simulator will give a warning if you have set it up that way.
But from implementation point of view it is a good idea to have all the same time scales.

2. I am not sure what do you want to do with #10 however remember that delays are not implementable in hardware. But the design of the delay you have done seems to be right. However it would always be a multiple of your clock time period.
 

    uglyduck

    Points: 2
    Helpful Answer Positive Rating

uglyduck

Junior Member level 2
Joined
Oct 31, 2005
Messages
23
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,281
Activity points
1,613
Thank you for your answer :)
About "timescale" it sounds reasonable - I have checked out several sources, but needed to be sure.
Anyway...
About the delay: the purpose of the delay I worked on, is to be used in a PWM module for a motor controller. Since I use a transistor H-bridge, it is known that there must be a "dead time" between the switching of transistors from the same branch. So I could not use a PWM that is convenient for audio application for example. Suppose we have two channels (normal case for two transistors) and let these channels are A and B. The algorithm must produce an impulse for channel A (proportional to the PWM input), make a pause (the fore-mentioned delay), then produce an impulse for channel B (proportional to the negation of the PWM input) and make a pause again. That's a complete cycle and that's all. I'm using three counters - for the ch. A, pause (that is constant and is about 1uSec) and ch.B. I have done two versions of this algorithm - behavioral and dataflow, but both versions are consuming over 35% of the resources of XC9572... I think that is too much and I'm sure there is a way to do this some simpler. But for now I have no more ideas. Using a bigger chip is easy, but is not the right solution.
Any idea ?

Cheers
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top