Periodically delayed clock

comes from your logic. It is any signal you want it to be.
re not familiar with the most fundamental nomenclature of digital logic des ign or if you don't understand the concepts of digital logic. I find both ideas equally implausible.
I understand concepts. I even know flip-flop, but the FF abbreviation wasn 't on my radar.
I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintai n the state specified as of the time of their last setting, so they output continually as a bit buffer.
I think D_in would be wired to my BUSY signal, and the SET input would be a sserted 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.
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
Loading thread data ...
onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin:
n comes from your logic. It is any signal you want it to be.
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.
sn't on my radar.
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.
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.
rewind ....
the code was:
that is a flopflip with clok enable; at every rising edge of fast_clk D_in get "stored" and appears on Q_out, IF and only if clock_enable is high
you busy signal goes to clock_enable
Reply to
lasselangwadtchristensen
gh
I understand. I'll try to work with that way of thinking.
If anyone's interested, here's my thinking on this type of circuit. I thin k a construction like this would make more sense in hardware definition sou rce code:
// Declared in global space BitObj goEnable; goEnable.D_in = BUSY; goEnable.set = @risingedge CLK;
// You can then reference this in your code anywhere: Q_out = goEnable.out;
The BitObj object would be a known class/construct that has two inputs, one output (logically), and it can then be logically wielded in that way. It can be setup as a static object somewhere in global space (a singleton), an d is then defined to be wired up as indicated with the Q_out reference.
In addition, other circuits later on could reference it simply by saying:
my_other_signal = goEnable.out;
And I would use that existing C/C++ knowledge base for how to write these t hings. They are more along the things I would write into Logician. We are , after all, creating an fully artificially constructed environment per our definition. It's fully logically constructed from the ground up given the constraints of the environment we're in (limitations / requirements of our target device if on an FPGA, or in our process technology for manufacturin g real silicon-based ICs).
The compiler should be able to work out how it should all be physically wir ed up, and provide information /
metrics about where there are inefficienci es, hot spots, etc.
I desire to work at that level of logic, and to have a more common set of t ools to be able to translate it from the ideal virtual world of design into the physical needs of the target device. I want the compiler / toolset to do that for me, and I desire to work with a more common / centralized know ledge base to other disciplines (such as C/C++ coding styles). The use of "then" and "end if;" for example ... replace them with { and }.
Just my thinking on this. It's one of the reasons I've had difficulty lear ning existing tools. I can envision another way to do it, and it frustrate s me that it isn't already written that way because it seems more logical.
Same thing with basic gates. I have renamed them to things that make sense to me:
Flip -- Logical NOT for Signal or Data (1 yields 0, 0 yields 1) Any1 -- Logical OR for Signal or Data (1 on any input 1) All1 -- Logical AND for Signal or Data (1 on all input 1) Any0 -- Logical NAND for Signal or Data (1 on any input 0) All0 -- Logical NOR for Signal or Data (1 on all input 0) Diff -- Logical XNOR for Signal or Data (1 on inputs are different) Same -- Logical XOR for Signal or Data (1 on inputs are same)
I think a student learning those terms would pick them up in 11 seconds, co mpared to trying to remember what the traditional terms mean, etc.
I have lots of ideas like this and I think if people would give me a chance I could positively impact this area of hardware prototyping and design.
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
Oops. These two should be reversed:
Any0 -- Logical NOR for Signal or Data (1 on any input 0) All0 -- Logical NAND for Signal or Data (1 on all input 0)
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
high
ink a construction like this would make more sense in hardware definition s ource code:
D_in is you data input, BUSY should be a enable signal telling it to ignore the clock edges
ne output (logically), and it can then be logically wielded in that way. I t can be setup as a static object somewhere in global space (a singleton), and is then defined to be wired up as indicated with the Q_out reference.
things. They are more along the things I would write into Logician. We a re, after all, creating an fully artificially constructed environment per o ur definition. It's fully logically constructed from the ground up given t he constraints of the environment we're in (limitations / requirements of o ur target device if on an FPGA, or in our process technology for manufactur ing real silicon-based ICs).
ired up, and provide information / metrics about where there are inefficien cies, hot spots, etc.
tools to be able to translate it from the ideal virtual world of design in to the physical needs of the target device. I want the compiler / toolset to do that for me, and I desire to work with a more common / centralized kn owledge base to other disciplines (such as C/C++ coding styles). The use o f "then" and "end if;" for example ... replace them with { and }.
arning existing tools. I can envision another way to do it, and it frustra tes me that it isn't already written that way because it seems more logical .
se to me:
compared to trying to remember what the traditional terms mean, etc.
ce I could positively impact this area of hardware prototyping and design.
you are trying to reinvent the wheel by refining "circular ring with spokes from rim to hub" to "round thing with some sticks in the middle" without fu lly understanding how a wheel works
Reply to
lasselangwadtchristensen
I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
n comes from your logic. It is any signal you want it to be.
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.
sn't on my radar.
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.
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 -+-
formatting link
Reply to
gnuarm.deletethisbit
_in comes from your logic. It is any signal you want it to be.
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.
wasn't on my radar.
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.
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.
gh
After being enabled... no?
Rick C.
Tesla referral code -++
formatting link
Reply to
gnuarm.deletethisbit
Ok, I am throwing in the towel. You need to read some basic logic design text books. You have no understanding at all of how this stuff works and you don't seem to be interested in learning from those who do.
Rick C.
Tesla referral code +--
formatting link
Reply to
gnuarm.deletethisbit
D_in comes from your logic. It is any signal you want it to be.
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.
n wasn't on my radar.
?
, 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.
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.
high
Sorry, it's late and I meant to say "inverted", not "enabled".
Reply to
gnuarm.deletethisbit
A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) works:
formatting link

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: 
 Click to see the full signature
Reply to
Stef
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.
Is that the same as a ripple carry counter? Why are they not good in an FPGA?
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
I see what you mean by ripple counter now.
Thank you.
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
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
Reply to
Rick C. Hodgin
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.
Reply to
David Brown
David Brown,
Your advice has prompted me to write my own tools sooner rather than later.
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
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.
Reply to
David Brown
te:
:
t_clk
ble is high
. I think a construction like this would make more sense in hardware defin ition source code:
ignore
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.
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.
orks:
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 +-+
formatting link
Reply to
gnuarm.deletethisbit
Nope. I was correct in my first posting. It should be:
Any0 -- Logical NAND for Signal or Data (1 on any input 0) All0 -- Logical NOR for Signal or Data (1 on all input 0)
Truth table:
NAND / NOR / Any 0 All 0
a b | o a b | o ---------- ---------- 0 0 | 1 0 0 | 1 0 1 | 1 0 1 | 0 1 0 | 1 1 0 | 0 1 1 | 0 1 1 | 0
--
Rick C. Hodgin
Reply to
Rick C. Hodgin
Most of us learn to walk before we learn to run. Give that a try. :)
Do you have a simple question using terminology we all share and understand?
Rick C.
Tesla referral code +-+
formatting link
Reply to
gnuarm.deletethisbit

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.