Periodically delayed clock - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Periodically delayed clock
On 2018-11-29 snipped-for-privacy@gmail.com wrote in comp.arch.fpga:
Quoted text here. Click to load it

A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) works:
http://electronics-course.com/d-flip-flop

Change the inputs on the symbol to see what happens. Or edit the timing
diagram by clicking and then hit 'simulate'

BTW: Be carefull with the ripple counter stuff at the end of the article.
That is not something you would want to use in an FPGA design.


--  
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

cursor address, n:
We've slightly trimmed the long signature. Click to see the full one.
Re: Periodically delayed clock
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quoted text here. Click to load it

I realized after I posted the D_in should be ~BUSY rather than BUSY.

But, that simulation is as I indicated:  @risingEdge of CLK strobes
the FF to set the value, and holds it until strobed again on the
next rising edge.

For the enable circuit, I would want that sustain for a full clock
cycle, so the ~BUSY input is tested and set at the clock's rising
edge, resulting in an enable that's high or low for the full duration
of that clock cycle.

The output Q is then AND gated with clock to signal the mext cycle,
which will only occur when BUSY is not asserted.

If ~BUSY and CLK were swapped, the FF would seem to be a pass-thru,
signaling CLK continuously whenever BUSY is not asserted, meaning it
would potentially signal a partial cycle when BUSY is de-asserted
mid-cycle.  That would be undesirable because that cycle's workload
may not complete in a partial cycle, resulting in error.

That's my understanding.  I would accept correction if I'm wrong.
I'm not here to be hard-headed ... it's just that I honestly believe
I understand it, and if I don't I'd like to be taught so I can know
the truth.

Quoted text here. Click to load it

Is that the same as a ripple carry counter?  Why are they not good
in an FPGA?

--  
Rick C. Hodgin

Re: Periodically delayed clock
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quoted text here. Click to load it

I see what you mean by ripple counter now.

Thank you.

--  
Rick C. Hodgin

Re: Periodically delayed clock
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quoted text here. Click to load it
te:
Quoted text here. Click to load it
mail.com wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it
..@gmail.com wrote:
Quoted text here. Click to load it
t_clk  
Quoted text here. Click to load it
ble is high
Quoted text here. Click to load it
.  I think a construction like this would make more sense in hardware defin
ition source code:
Quoted text here. Click to load it
 ignore  
Quoted text here. Click to load it
 because you want a full clock cycle resolution on the delay, and if BUSY i
s asserted at the start of a cycle, it should delay the entire cycle.
Quoted text here. Click to load it
gn text books.  You have no understanding at all of how this stuff works an
d you don't seem to be interested in learning from those who do.  
Quoted text here. Click to load it
orks:
Quoted text here. Click to load it

You also don't want to use the preset or clear inputs.  They are async and  
so tricky to use in a design.  Sometimes async inputs are used in HDL to co
ntrol the state of FFs on configuration, but that can be tricky too.  Much  
better to either use synchronous inputs or none at all and let the logic st
art up by defining all possible inputs.  

When using an async input you have to make no assumptions about the timing  
with respect to the clock which makes it very hard to do properly.  

  Rick C.  

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

Re: Periodically delayed clock
On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote:
Quoted text here. Click to load it

BUSY here should be ~BUSY.  And when I say "clock should be the enable," I meant CLK should strobe the set input on the FF.  In that way, Q is sustained for an entire clock cycle and there are no partial clocks visible on Q.

--  
Rick C. Hodgin

Re: Periodically delayed clock
On 29/11/18 10:53, Rick C. Hodgin wrote:
Quoted text here. Click to load it

I get the feeling that you have a partial understanding of how
flip-flops work, but are missing some details.  You also understand much
of the higher level logic, but are unaware of the practical issues in
FPGA design (such as clock distribution and timings).  And you have your
terminology completely garbled.  Imagine that "clock", "enable",
"strobe", "set", "input" and "FF" are all keywords - they all have very
specific meanings in this context.  The "enable" input to a flip-flop
has a specific function, as does the "set" input - when you use these
words to mean something else, confusion and frustration is inevitable.

There really is no choice here.  You /must/ get yourself a book on logic
design with FPGA's - or at least go through a comprehensive set of
tutorials.  You need to study hard at the basics, and learn the
terminology.  You have to do the simple exercises - make the two-bit
counter, the grey encoder/decoder, the traffic lights.  And the sooner
you do it, the better - otherwise you will be talking to yourself with
no way to get help from others, and you will re-make all the same
mistakes of every logic designer for the past four decades.

I know you want to dive in and make your cpu design.  But you need to
take a step back and learn how this works, and learn the basics first -
it will get you to your goal faster in the long run.

And once you have learned the basics of VHDL or Verilog, and can make
your flip-flops and make simple designs with them, and verified them
with simulation (using standard tools, not your own ones), and verified
them on a real board, then you are ready to start thinking bigger.

Re: Periodically delayed clock
David Brown,

Your advice has prompted me to write my own tools sooner rather than later.

--  
Rick C. Hodgin

Re: Periodically delayed clock
On 29/11/18 15:05, Rick C. Hodgin wrote:
Quoted text here. Click to load it

That will give you a few things:

1. You will have terminology that you understand.
2. You will have a high-level view that fits your ideas and desires.
3. You will not be able to talk to anyone else, or learn from anywhere
else, or work with anyone else.
4. You will make lots of key, fundamental mistakes.
5. Your results will be massively inefficient.
6. You will never be finished.

You /cannot/ create better tools or a better way to work with hardware
design until you have a far clearer understanding of how it is done
today, and what existing tools do.  You cannot avoid learning by
inventing your own systems - that is a recipe for disaster.


I gave a strong recommendation for how you can make progress.  You are
so keen on running (no one can fault your optimism or enthusiasm!) that
you have not learned how to walk.


One thing I did not say in my last post is where you should go once you
have an understanding of Verilog or VHDL, and how digital logic works
and how it is designed.  My recommendation is that you then leave these
and use higher level tools that generate Verilog and/or VHDL as an
output.  I would suggest MyHDL as a starting choice, but there are
others.  And it is certainly possible for you to write your own tools at
that level - this is common amongst processor designers.  But you need
to understand what is going on underneath before you can do this
correctly - you need to understand how the fundamental parts of digital
logic work, how to make successful synchronous logic, and how to get the
results you want from an FPGA.



Re: Periodically delayed clock
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.
com wrote:
Quoted text here. Click to load it
l.com wrote:
Quoted text here. Click to load it
_in comes from your logic.  It is any signal you want it to be.
Quoted text here. Click to load it
ou are not familiar with the most fundamental nomenclature of digital logic
 design or if you don't understand the concepts of digital logic.  I find b
oth ideas equally implausible.
Quoted text here. Click to load it
wasn't on my radar.
Quoted text here. Click to load it
they are explicitly set to 0 or 1, and do not actually flip flop.  They mai
ntain the state specified as of the time of their last setting, so they out
put continually as a bit buffer.
Quoted text here. Click to load it
be asserted on each clock's rising edge.  This would consistently set the F
F to 0 or 1 based on the BUSY input, and it would sustain throughout the en
tire clock cycle, being re-SET each time to the new state.
Quoted text here. Click to load it
gh

After being enabled... no?  

  Rick C.  

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

Re: Periodically delayed clock
On Thursday, November 29, 2018 at 1:55:37 AM UTC-5, snipped-for-privacy@gmail.com
 wrote:
Quoted text here. Click to load it
l.com wrote:
Quoted text here. Click to load it
ail.com wrote:
Quoted text here. Click to load it
 D_in comes from your logic.  It is any signal you want it to be.
Quoted text here. Click to load it
 you are not familiar with the most fundamental nomenclature of digital log
ic design or if you don't understand the concepts of digital logic.  I find
 both ideas equally implausible.
Quoted text here. Click to load it
n wasn't on my radar.
Quoted text here. Click to load it
?
Quoted text here. Click to load it
, they are explicitly set to 0 or 1, and do not actually flip flop.  They m
aintain the state specified as of the time of their last setting, so they o
utput continually as a bit buffer.
Quoted text here. Click to load it
d be asserted on each clock's rising edge.  This would consistently set the
 FF to 0 or 1 based on the BUSY input, and it would sustain throughout the  
entire clock cycle, being re-SET each time to the new state.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
high

Sorry, it's late and I meant to say "inverted", not "enabled".

Re: Periodically delayed clock
On Wednesday, November 28, 2018 at 3:06:57 PM UTC-5, Rick C. Hodgin wrote:
Quoted text here. Click to load it
com wrote:
Quoted text here. Click to load it
n comes from your logic.  It is any signal you want it to be.
Quoted text here. Click to load it
 are not familiar with the most fundamental nomenclature of digital logic d
esign or if you don't understand the concepts of digital logic.  I find bot
h ideas equally implausible.
Quoted text here. Click to load it
sn't on my radar.
Quoted text here. Click to load it
ey are explicitly set to 0 or 1, and do not actually flip flop.  They maint
ain the state specified as of the time of their last setting, so they outpu
t continually as a bit buffer.
Quoted text here. Click to load it
 asserted on each clock's rising edge.  This would consistently set the FF  
to 0 or 1 based on the BUSY input, and it would sustain throughout the enti
re clock cycle, being re-SET each time to the new state.

This is a very slow and painful way to educate you.  I think what you are c
alling the SET input is what the rest of the universe calls the clock.  No?
  

Where else would this FF be used?  

  Rick C.  

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

Re: Periodically delayed clock
onsdag den 28. november 2018 kl. 19.13.21 UTC+1 skrev Rick C. Hodgin:
Quoted text here. Click to load it
.com wrote:
Quoted text here. Click to load it
r" means.
Quoted text here. Click to load it
trated example from a reference CPU design written for the purposes of inst
ruction and education:
Quoted text here. Click to load it
erations will take longer to compute than the clock allows.  It is only on  
those stages that I want there to be a delay here.
Quoted text here. Click to load it
r 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.
Quoted text here. Click to load it
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 re
al-world tools.  I also encounter resistance when I approach others with my
 thinking, rather than the hard and fast specs / terms other people are use
d 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 l
ost on is the mechanics of making it happen in real-world tools, and not th
e theory underlying it.
Quoted text here. Click to load it

I think you are meeting resistance because you are try to do things in a wa
y  
people learned long time ago was a bad idea, and that getting lost in the m
echanics 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_




Re: Periodically delayed clock
On Wednesday, November 28, 2018 at 1:48:41 PM UTC-5, lasselangwad...@gmail.
com wrote:
Quoted text here. Click to load it
way  
Quoted text here. Click to load it
 mechanics probably means you haven't quite figured it out.

No doubt.  I don't have a mentor or tutor to help guide me, so I'm having t
o do it all on my own.  I think in terms of ideal scenarios, and not practi
cal real-world scenarios, and I have no doubts I'll get caught up in the tr
anslation form the ideal into a real-world implementation.

Quoted text here. Click to load it
ge

I'll work on getting correct technology.  And I ask for a little grace unti
l I get it all sorted please. :-)

Thank you.

--  
Rick C. Hodgin

Re: Periodically delayed clock
I came across this sermon today.  It speaks of these very things I'm talking about here, about starting a foundation upon God and holiness, and not upon other things, and then building everything else which exists atop that foundation:

    A.W. Tozer -- "Everything By Prayer"
    
https://www.youtube.com/watch?v75%LunLW2mMg


Tozer died in 1963, and these audio sermons are some of what remain of his teachings, a 44-year stint in ministry.

    https://en.wikipedia.org/wiki/A._W._Tozer

--  
Rick C. Hodgin

Re: Periodically delayed clock
Since my last post I have been working on my Logician tool.  I currently ha
ve it modeling a simple bit storage device with four gates, two inputs, one
 output, three other devices, and 13 bit lines.  It provides a type of GtkW
ave output.  I'm currently working on a true visualization of the circuits  
along with a type of debugger environment for examining individual circuits
 in local / watch windows, as well as a single-step debugger.

Once it's all coded and validated, I'll move on to larger tests.  I plan to
 offer hot-swap DLL functions which replace large logic units once they're  
validated, to replace their bits in and bits out with custom DLL code (for  
faster simulations).

Logician plans to be dynamic and extensible.

When it is ready for a beta release, I'll post the Windows-based executable
 and source code online along with a video and various examples explaining  
how to use them.  My first target will be the Scott CPU from the book "But  
How Do It Know?"  It is a simple 8-bit processor designed to teach people h
ow computers work fundamentally.  It will be sufficient for a visualization
 and operational demonstration of its features in real-time.

I eventually plan to develop my CPUs in this tool, and to export the net it
 creates to Verilog source code for use in a real FPGA.  I could use help w
orking with Verilog and FPGA tools when that time comes.

--  
Rick C. Hodgin

Re: Periodically delayed clock
On Thursday, December 6, 2018 at 2:46:07 PM UTC-5, Rick C. Hodgin wrote:
Quoted text here. Click to load it
have it modeling a simple bit storage device with four gates, two inputs, o
ne output, three other devices, and 13 bit lines.  It provides a type of Gt
kWave output.  I'm currently working on a true visualization of the circuit
s along with a type of debugger environment for examining individual circui
ts in local / watch windows, as well as a single-step debugger.
Quoted text here. Click to load it
to offer hot-swap DLL functions which replace large logic units once they'r
e validated, to replace their bits in and bits out with custom DLL code (fo
r faster simulations).
Quoted text here. Click to load it
le and source code online along with a video and various examples explainin
g how to use them.  My first target will be the Scott CPU from the book "Bu
t How Do It Know?"  It is a simple 8-bit processor designed to teach people
 how computers work fundamentally.  It will be sufficient for a visualizati
on and operational demonstration of its features in real-time.
Quoted text here. Click to load it
it creates to Verilog source code for use in a real FPGA.  I could use help
 working with Verilog and FPGA tools when that time comes.

How do you plan to deal with clock enables?  

  Rick C.  

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

Re: Periodically delayed clock
On Thursday, December 6, 2018 at 9:58:46 PM UTC-5, snipped-for-privacy@gmail.com  
wrote:
Quoted text here. Click to load it

Logiciam supports a CLK device.  It is a traditional periodic square wave f
orm outputting 1s and 0s period-based.  That putput could be routed through
 AND gates, what I call All1 gates, based on system flags, and would advanc
e a stepper when things are allowed to progress, per my original design int
ent as indicated in this thread.

However, I'm going to try to go with an asynchronous design.

--  
Rick C. Hodgin

Re: Periodically delayed clock
On Friday, December 7, 2018 at 3:31:19 AM UTC-5, Rick C. Hodgin wrote:
Quoted text here. Click to load it
m wrote:
Quoted text here. Click to load it
 form outputting 1s and 0s period-based.  That output could be routed throu
gh AND gates, what I call All1 gates, based on system flags, and would adva
nce a stepper when things are allowed to progress, per my original design i
ntent as indicated in this thread.

I watched a video this morning on the 6502.  It contains the very circuit I
 was describing above, with a clock generator feeding in to a small unit wh
ich receives the equivalent of busy flags from other parts of the system be
fore advancing its stepper.  I about fell off the treadmill when I saw it.

Quoted text here. Click to load it

--  
Rick C. Hodgin


Re: Periodically delayed clock
On Friday, December 7, 2018 at 3:31:19 AM UTC-5, Rick C. Hodgin wrote:
Quoted text here. Click to load it
m wrote:
Quoted text here. Click to load it
 form outputting 1s and 0s period-based.  That putput could be routed throu
gh AND gates, what I call All1 gates, based on system flags, and would adva
nce a stepper when things are allowed to progress, per my original design i
ntent as indicated in this thread.
Quoted text here. Click to load it

I can't say I understand any of the above other than the "asynchronous" des
ign part.  There lies madness.  I have done async design and it is not easy
.  A small FSM is not too hard, but anything larger is much harder.  FPGAs  
are not intended for async design and make it all *very* hard.  

Do you know how to implement sequential logic asynchronously?  

  Rick C.  

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

Site Timeline