EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Periodically delayed clock

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Periodically delayed clock

Goto page 1, 2, 3, 4, 5  Next

Rick C. Hodgin
Guest

Tue Nov 27, 2018 5:45 pm   



I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.

--
Rick C. Hodgin


Guest

Tue Nov 27, 2018 6:45 pm   



tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
Quote:
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.


don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead


Guest

Tue Nov 27, 2018 7:45 pm   



On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail.com wrote:
Quote:
tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.


don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead


+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.

Rick C.

Tesla referral code - https://ts.la/richard11209

Rick C. Hodgin
Guest

Tue Nov 27, 2018 8:45 pm   



On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.com wrote:
Quote:
On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail..com wrote:
don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.


LL, Rick C, thank you for your reply.

I'm not sure what "clock enables" means. Is there an example?

--
Rick C. Hodgin


Guest

Tue Nov 27, 2018 10:45 pm   



On Tuesday, November 27, 2018 at 4:24:16 PM UTC-5, Rick C. Hodgin wrote:
Quote:
On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
I'm not sure what "clock enables" means. Is there an example?

FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.

Part of my goals on this project are to create a static design that can be clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and still work, to clock on a mechanical external trigger, and to run on the various system clocks.

My thinking has been that if I'm able to get it working properly at my target clock speed, then everything else should work if I underclock it, and even bring it down to a halt.

With such a design, would the ability to have variable clock pulse widths still be something to be avoided? Or is the whole idea of such a wildly variable clock speed a pipe dream? Smile


Absolutely avoid variable width clock pulses for the reasons given. Clock enables are the perfect way to slow your speed, enabling the design only on the clock cycles you wish to advance the processing. By removing the enable the entire design stops. Raise the enable for one clock cycle and the design advances one step.

It is always good to consider how you will debug a design in the chip. But you should be testing in simulation to get rid of 99.99% of the bugs before you ever load it into an FPGA.

Rick C.

Tesla referral code -- https://ts.la/richard11209

Rick C. Hodgin
Guest

Tue Nov 27, 2018 10:45 pm   



On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.com wrote:
Quote:
On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
I'm not sure what "clock enables" means. Is there an example?

FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.


Part of my goals on this project are to create a static design that can be clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and still work, to clock on a mechanical external trigger, and to run on the various system clocks.

My thinking has been that if I'm able to get it working properly at my target clock speed, then everything else should work if I underclock it, and even bring it down to a halt.

With such a design, would the ability to have variable clock pulse widths still be something to be avoided? Or is the whole idea of such a wildly variable clock speed a pipe dream? :-)

--
Rick C. Hodgin


Guest

Tue Nov 27, 2018 10:45 pm   



On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
Quote:
On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail.com wrote:
don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.

LL, Rick C, thank you for your reply.

I'm not sure what "clock enables" means. Is there an example?


FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.

Rick C.

Tesla referral code + https://ts.la/richard11209

HT-Lab
Guest

Wed Nov 28, 2018 11:45 am   



On 27/11/2018 17:36, lasselangwadtchristensen_at_gmail.com wrote:
Quote:
tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.


don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead



I also agree with statement,however for completeness most (if not all)
modern synthesis tools will remove the AND gate in front of the clock
input and re-connect the "gate signal" to the FF's CE pin (there are
other constructs as well).

FPGA are used for ASIC prototyping and for this reason most synthesis
tools can handle ASIC coding styles like gate clocks, ripple counters,
clock muxes and they even convert DesignWare blocks.

My additional advice to Rick would be spend some time on adding pipeline
stages and simply stall the units if no input data is available or feed
them with NOPs. If you want to give units more clock cycles delays then
look into multicyle path constructs and constraints (which can sometimes
be a real pain). You might also want to add some assertions (on the path
control logic) to confirm the path is always multicyle (>1 clock cycle).

Good luck,
Hans
www.ht-lab.com

Rick C. Hodgin
Guest

Wed Nov 28, 2018 4:45 pm   



How would I implement a clock enable differently than I'm doing here?


CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
CLK still runs consistent and periodic, but the advances are triggered
off CLK2, which could be renamed TRIGGER or something.

??

--
Rick C. Hodgin


Guest

Wed Nov 28, 2018 5:45 pm   



On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:
Quote:
How would I implement a clock enable differently than I'm doing here?


CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
CLK still runs consistent and periodic, but the advances are triggered
off CLK2, which could be renamed TRIGGER or something.

??

--
Rick C. Hodgin


I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.

I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

Rick C.

Tesla referral code -+ https://ts.la/richard11209


Guest

Wed Nov 28, 2018 6:45 pm   



On Wednesday, November 28, 2018 at 12:22:12 PM UTC-5, Rick C. Hodgin wrote:
Quote:
On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail..com wrote:
On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:

CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.

The CLK2 output is the trigger for the next event.


You seem to be speaking in your own terms. I don't know what a "trigger" means. Digital design signals generally have clocks and logic. Logic can be clock enables or data. By "trigger" do you mean a clock enable? If you are talking about a clock enable, it should not be generated by gating the clock.

Let me make this simple. NEVER GATE THE CLOCK when working in FPGAs. In fact, I will make this even more general, NEVER USE THE CLOCK AS PART OF THE LOGIC. There may be a very few cases where it makes sense to use the clock as part of your logic, but they are exceedingly few and you have to understand all the implications. I'm not willing to go through all the important issues with someone who is dealing with the basics of logic design. So for now learn the basics, then maybe you can learn the rest later.

So for now consider all logic to be the same, based on other logic signals only and not the clock. This also applies to your busy reset.


Quote:
I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

The little bit above is close to the code, but there are some caveats on which edge to trigger.

I'll put on my thinking cap and get back to you.


Don't try to worry about "which clock edge". Always work with the positive edge until you better understand what you are doing. Like using the clock in logic, there are few situations where working on the opposite edge of the clock will gain you any advantages and it adds significantly to the issues of verifying timing.

The clock should be used for one thing only, to drive the clock input of FFs, preferably all triggered from the same edge.

Rick C.

Tesla referral code +- https://ts.la/richard11209

Rick C. Hodgin
Guest

Wed Nov 28, 2018 6:45 pm   



On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail.com wrote:
Quote:
On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:

CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.


The CLK2 output is the trigger for the next event.

> I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

The little bit above is close to the code, but there are some caveats on which edge to trigger.

I'll put on my thinking cap and get back to you.

--
Rick C. Hodgin

Rick C. Hodgin
Guest

Wed Nov 28, 2018 7:45 pm   



On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail.com wrote:
> You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.

--
Rick C. Hodgin


Guest

Wed Nov 28, 2018 7:45 pm   



On Wednesday, November 28, 2018 at 1:13:21 PM UTC-5, Rick C. Hodgin wrote:
Quote:
On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail..com wrote:
You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.


Ok, you are trying to generate an output called "trigger". You might try another name. So what is your question?

Thinking in your own terms and names means you will find it hard to communicate with others. I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

Personally I think your problem is you are trying to build an aircraft carrier before you understand how to build a hinge. It would be much better if you tried working on much simpler projects and worked up to your massive CPU design. But you are free to learn any way you want.

So what is your question?

Rick C.

Tesla referral code ++ https://ts.la/richard11209


Guest

Wed Nov 28, 2018 8:45 pm   



onsdag den 28. november 2018 kl. 19.13.21 UTC+1 skrev Rick C. Hodgin:
Quote:
On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail..com wrote:
You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.


I think you are meeting resistance because you are try to do things in a way
people learned long time ago was a bad idea, and that getting lost in the mechanics probably means you haven't quite figured it out.


all you need is clk and busy, don't gate the clock and only use rising edge


always@(posedge clk)
begin
if(!bsy)
cnt <= cnt + 1;
end
_ _ _ _
clk ___| |_| |_| |_| |_
___
bsy _______| |_______
___ ___ _______ ___
cnt _0_|_1_|_2_____|_3_

Goto page 1, 2, 3, 4, 5  Next

elektroda.net NewsGroups Forum Index - FPGA - Periodically delayed clock

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map