module freq_doubler (clockin, clockout);
input clockin;
output clockout;
clockout = (twice the frequency of clockin);
endmodule;
Could someone please, help me with this. Thanks
In current technologies, it is impossible to multiply a frequency
with pure technology-independent RTL coding. You must use elements
of vendor library which takes clock as input and outputs clock as
multiplied.
Utku
if you want a synthesizable solution you're basicly out of luck - what
you need is a PLL/DLL - something best done by a physical designer (to be
fair I guess a DLL with extracted delays could be made to work in Verilog).
If you want a non-synthesizable solution to say model a PLL you can do
something like:
`timescale 1ps/1ps
module freq_doubler (clockin, clockout);
time start, period;
output clockout;
reg clockout;
input clockin;
initial begin
period = 0;
start = 0;
forever begin
@(posedge clockin);
period = $time - start;
start = $time;
end
end
initial begin
clockout = 0;
#0; // let the above run
forever @(clockin) begin
#0; // allow the code above to run
while (period > 0) begin :core
time next;
next = $time+period;
clockout = 1;
#((next-$time)/4);
clockout = 0;
#((next-$time)/3);
clockout = 1;
#((next-$time)/2);
clockout = 0;
#(next-$time);
end
end
end
endmodule
make sure you leave it a few clocks to settle at the beginning of time
Paul Campbell
pa...@verifarm.com
If you're not worried about duty cycle of the generated clock, you can
just use an XOR strategy with delay cells (again, those are vendor
specific). But if this is just for simulation try:
module freq_double( clockin, clockout);
parameter pause_time = 250; //1/4 of input clock period
input clockin;
output clockout;
wire #pause_time delayed_clock = clockin;
assign clock_out = clockin ^ delayed_clock;
endmodule
--
Jason Rosinski
Mitel Semiconductor
Jason_R...@mitel.com
Take a look at: http://www.deepchip.com/items/0308-12.html
You'll find an XOR and a NOT used with a FF to do what you want. This
should do the behavior you want and be careful to note that it depends
on the delay of the NOT gate. If you're foolish enough to want to
actually make such a circuit in a chip, you're going to be spending a
lot of time with your layout guy plus your fab will make you sign all
sorts of "We're Not Responsible For This" paperwork. A better route
is to use a PLL from what I've heard and seen. But, if all you're
seeking is clock doubling behavior for simulation purposes only, this
URL gives you the idea of what to code up in your Verilog.
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
============================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 11,000+ other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jco...@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
Just try to use this one:
module clk2(in_clk, out_clk);
input in_clk;
output out_clk;
wire out_clk_bar;
dff dff1(.d(out_clk_bar), .q(out_clk), .clk(in_clk), .clrn(1'b1),
.prn(1'b1));
not not1(out_clk_bar, out_clk);
endmodule
Nikolaj Larionov
On Thu, 05 Apr 2001 11:01:11 -0400, David Johnson <djo...@cisco.com>
wrote:
Cheers!
Benny Tan
1245hrs
030501
Plonker wrote:
>
> HI
>
> Just try to use this one:
>
> module clk2(in_clk, out_clk);
>
> input in_clk;
> output out_clk;
>
> wire out_clk_bar;
>
> dff dff1(.d(out_clk_bar), .q(out_clk), .clk(in_clk), .clrn(1'b1),
> .prn(1'b1));
> not not1(out_clk_bar, out_clk);
>
> endmodule
>
> Nikolaj Larionov
>
--
Kay(Benny) C Tan
Department of Electronics and Electrical Engineering
The University of Edinburgh
King's Buildings
Mayfield Rd
Edinburgh EH9 3JL
(Int +44) 131 650 5658
(Int +44) 131 650 6554 (FAX)
Benn...@ee.ed.ac.uk
(Dunno if I would actually trust the quality of a clock signal
generated like this though :)
"Kay(Benny) C Tan" <Benn...@ee.ed.ac.uk> wrote in message
news:3AF144D7...@ee.ed.ac.uk...
Using a (Digital) PLL to double one,
constant frequency is overkill.
One XOR gate and an even number of
inverters will do the trick.
Just feed your clock into one xor input,
connect the inverters in series, connect
the output of the last inverter to the 2nd
xor input, and the input of the 1st inverter
to your clock.
The xor output will have a duty cycle
<< 50%. It will stay high for a time equal
to the delay time of the inverters.
This configuration has a name: Digital
Diferentiator, in analogy to the analog
RC network (1st order high pass filter).
If you want a 50% duty cycle, think a bit
or contact me. I am only a colleague.
Regards!
>Subject: Re: Clock Frequency Doubler
>From: "Kay(Benny) C Tan" Benn...@ee.ed.ac.uk
>Date: 5/3/01 4:45 AM US Mountain Standard Time
>Message-id: <3AF144D7...@ee.ed.ac.uk>
the 'bandwidth' of the wire and buffers that the pulsed
2x clock drives may need to be much higher than anything
else in the design. in effect, the 2x clock has a pulse width
related to the delay - and '2-inverters' just plain isn't enough
(1.0/0.2ns -> 5ghz).
it would help if you could build the delay circuit to at least
model the 'lowest bandwidth point' (ie, a heavily loaded
clock driver).
i've used this technique, but provided myself (via i2c configuation
capabilities already on the die) a programmable delay, to give myself
some wiggle room if i ran into the 'pulse-too-narrow-to-propagate'
syndrom that i've described here.
a related, less likely pitfall occurs when the duty cycle of the
input clock is already badly skewed.
optimally, if a copy of the 1x clock is also used on the die, the 1x
clocks would be delayed by the same amount as the 2x-clocks, to
minimize hold time issues crossing between the two domains.
lastly, not all xor's provide symmetric delay for rise/fall, and this
can add to the apparent (dc-like) jitter, and make crossing to/from
the 2x-clock domain into the 1x-clock domain harder than it first
appears.
-elh