Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.=
com wrote:
> rewind ....
>=20
> the code was:
>=20
> > if (rising_edge(fast_clk)) then
> > if (clock_enable_a =3D '1') then
> > Q_out <=3D D_in;
> > end if;
> > end if;=20
>=20
> that is a flopflip with clok enable; at every rising edge of fast_clk=20
> D_in get "stored" and appears on Q_out, IF and only if clock_enable is hi=
gh
>=20
> you busy signal goes to clock_enable
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 =3D BUSY;
goEnable.set =3D @risingedge CLK;
// You can then reference this in your code anywhere:
Q_out =3D 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 =3D 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.
--=20
Rick C. Hodgin
Article: 160801
On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote:
> Any0 -- Logical NAND for Signal or Data (1 on any input 0)
> All0 -- Logical NOR for Signal or Data (1 on all input 0)
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
Article: 160802
onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
> On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmai=
l.com wrote:
> > rewind ....
> >=20
> > the code was:
> >=20
> > > if (rising_edge(fast_clk)) then
> > > if (clock_enable_a =3D '1') then
> > > Q_out <=3D D_in;
> > > end if;
> > > end if;=20
> >=20
> > that is a flopflip with clok enable; at every rising edge of fast_clk=
=20
> > D_in get "stored" and appears on Q_out, IF and only if clock_enable is =
high
> >=20
> > you busy signal goes to clock_enable
>=20
> I understand. I'll try to work with that way of thinking.
>=20
> If anyone's interested, here's my thinking on this type of circuit. I th=
ink a construction like this would make more sense in hardware definition s=
ource code:
>=20
> // Declared in global space
> BitObj goEnable;
> goEnable.D_in =3D BUSY;
> goEnable.set =3D @risingedge CLK;
D_in is you data input, BUSY should be a enable signal telling it to ignore=
=20
the clock edges =20
>=20
> // You can then reference this in your code anywhere:
> Q_out =3D goEnable.out;
>=20
> The BitObj object would be a known class/construct that has two inputs, o=
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.
>=20
> In addition, other circuits later on could reference it simply by saying:
>=20
> my_other_signal =3D goEnable.out;
>=20
> And I would use that existing C/C++ knowledge base for how to write these=
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).
>=20
> The compiler should be able to work out how it should all be physically w=
ired up, and provide information / metrics about where there are inefficien=
cies, hot spots, etc.
>=20
> I desire to work at that level of logic, and to have a more common set of=
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 }.
>=20
> Just my thinking on this. It's one of the reasons I've had difficulty le=
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=
.
>=20
> Same thing with basic gates. I have renamed them to things that make sen=
se to me:
>=20
> 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)
>=20
> I think a student learning those terms would pick them up in 11 seconds, =
compared to trying to remember what the traditional terms mean, etc.
>=20
> I have lots of ideas like this and I think if people would give me a chan=
ce I could positively impact this area of hardware prototyping and design.
>=20
you are trying to reinvent the wheel by refining "circular ring with spokes=
=20
from rim to hub" to "round thing with some sticks in the middle" without fu=
lly understanding how a wheel works
Article: 160803On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote: > onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin: > > On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote: > > > rewind .... > > > > > > the code was: > > > > > > > if (rising_edge(fast_clk)) then > > > > if (clock_enable_a = '1') then > > > > Q_out <= D_in; > > > > end if; > > > > end if; > > > > > > 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 > > > > 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 think a construction like this would make more sense in hardware definition source code: > > > > // Declared in global space > > BitObj goEnable; > > goEnable.D_in = BUSY; > > goEnable.set = @risingedge CLK; > > D_in is you data input, BUSY should be a enable signal telling it to ignore > the clock edges > > > > > // You can then reference this in your code anywhere: > > Q_out = goEnable.out; 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. HodginArticle: 160804
On Wednesday, November 28, 2018 at 3:06:57 PM UTC-5, Rick C. Hodgin wrote: > On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.= com wrote: > > FF means Flip Flop, the basic element of storage in digital logic. D_i= n comes from your logic. It is any signal you want it to be. > > > > I don't know if we are simply having communication problems because you= 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. >=20 > I understand concepts. I even know flip-flop, but the FF abbreviation wa= sn't on my radar. >=20 > > What do you call a flip flop? What would you use as the data input? >=20 > I have thought of them as bit storage. And as I understand their use, th= 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. >=20 > I think D_in would be wired to my BUSY signal, and the SET input would 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 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?= =20 Where else would this FF be used?=20 Rick C.=20 Tesla referral code -+- https://ts.la/richard11209Article: 160805
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.= com wrote: > onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin: > > On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmai= l.com wrote: > > > FF means Flip Flop, the basic element of storage in digital logic. D= _in comes from your logic. It is any signal you want it to be. > > > > > > I don't know if we are simply having communication problems because y= 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. > >=20 > > I understand concepts. I even know flip-flop, but the FF abbreviation = wasn't on my radar. > >=20 > > > What do you call a flip flop? What would you use as the data input? > >=20 > > 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 mai= ntain the state specified as of the time of their last setting, so they out= put continually as a bit buffer. > >=20 > > I think D_in would be wired to my BUSY signal, and the SET input would = 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. > >=20 >=20 > rewind .... >=20 > the code was: >=20 > > if (rising_edge(fast_clk)) then > > if (clock_enable_a =3D '1') then > > Q_out <=3D D_in; > > end if; > > end if;=20 >=20 > that is a flopflip with clok enable; at every rising edge of fast_clk=20 > D_in get "stored" and appears on Q_out, IF and only if clock_enable is hi= gh >=20 > you busy signal goes to clock_enable After being enabled... no?=20 Rick C.=20 Tesla referral code -++ https://ts.la/richard11209Article: 160806
On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote: > On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote: > > onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin: > > > On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote: > > > > rewind .... > > > > > > > > the code was: > > > > > > > > > if (rising_edge(fast_clk)) then > > > > > if (clock_enable_a = '1') then > > > > > Q_out <= D_in; > > > > > end if; > > > > > end if; > > > > > > > > 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 > > > > > > 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 think a construction like this would make more sense in hardware definition source code: > > > > > > // Declared in global space > > > BitObj goEnable; > > > goEnable.D_in = BUSY; > > > goEnable.set = @risingedge CLK; > > > > D_in is you data input, BUSY should be a enable signal telling it to ignore > > the clock edges > > > > > > > > // You can then reference this in your code anywhere: > > > Q_out = goEnable.out; > > 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. 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 +-- https://ts.la/richard11209Article: 160807
On Thursday, November 29, 2018 at 1:55:37 AM UTC-5, gnuarm.del...@gmail.com= wrote: > On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmai= l.com wrote: > > onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin: > > > On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gm= ail.com wrote: > > > > FF means Flip Flop, the basic element of storage in digital logic. = D_in comes from your logic. It is any signal you want it to be. > > > > > > > > I don't know if we are simply having communication problems because= 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. > > >=20 > > > I understand concepts. I even know flip-flop, but the FF abbreviatio= n wasn't on my radar. > > >=20 > > > > What do you call a flip flop? What would you use as the data input= ? > > >=20 > > > 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 m= aintain the state specified as of the time of their last setting, so they o= utput continually as a bit buffer. > > >=20 > > > I think D_in would be wired to my BUSY signal, and the SET input woul= 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. > > >=20 > >=20 > > rewind .... > >=20 > > the code was: > >=20 > > > if (rising_edge(fast_clk)) then > > > if (clock_enable_a =3D '1') then > > > Q_out <=3D D_in; > > > end if; > > > end if;=20 > >=20 > > that is a flopflip with clok enable; at every rising edge of fast_clk= =20 > > D_in get "stored" and appears on Q_out, IF and only if clock_enable is = high > >=20 > > you busy signal goes to clock_enable >=20 > After being enabled... no?=20 >=20 > Rick C.=20 >=20 > Tesla referral code -++ https://ts.la/richard11209 Sorry, it's late and I meant to say "inverted", not "enabled".Article: 160808
On 2018-11-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga: > On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote: >> On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote: >> > onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin: >> > > On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote: >> > > > rewind .... >> > > > >> > > > the code was: >> > > > >> > > > > if (rising_edge(fast_clk)) then >> > > > > if (clock_enable_a = '1') then >> > > > > Q_out <= D_in; >> > > > > end if; >> > > > > end if; >> > > > >> > > > 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 >> > > >> > > 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 think a construction like this would make more sense in hardware definition source code: >> > > >> > > // Declared in global space >> > > BitObj goEnable; >> > > goEnable.D_in = BUSY; >> > > goEnable.set = @risingedge CLK; >> > >> > D_in is you data input, BUSY should be a enable signal telling it to ignore >> > the clock edges >> > >> > > >> > > // You can then reference this in your code anywhere: >> > > Q_out = goEnable.out; >> >> 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. > > 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. 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: "Hello, cursor!" -- Stan Kelly-Bootle, "The Devil's DP Dictionary"Article: 160809
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote: > 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' 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. > 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. Is that the same as a ripple carry counter? Why are they not good in an FPGA? -- Rick C. HodginArticle: 160810
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote: > 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. I see what you mean by ripple counter now. Thank you. -- Rick C. HodginArticle: 160811
On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote: > 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. 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. HodginArticle: 160812
On 29/11/18 10:53, Rick C. Hodgin wrote: > On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin > wrote: >> 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. > > 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. > 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.Article: 160813
David Brown, Your advice has prompted me to write my own tools sooner rather than later. -- Rick C. HodginArticle: 160814
On 29/11/18 15:05, Rick C. Hodgin wrote: > David Brown, > > Your advice has prompted me to write my own tools sooner rather than later. > 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.Article: 160815
On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote: > On 2018-11-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga: > > On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wro= te: > >> On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@g= mail.com wrote: > >> > onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin= : > >> > > On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad.= ..@gmail.com wrote: > >> > > > rewind .... > >> > > >=20 > >> > > > the code was: > >> > > >=20 > >> > > > > if (rising_edge(fast_clk)) then > >> > > > > if (clock_enable_a =3D '1') then > >> > > > > Q_out <=3D D_in; > >> > > > > end if; > >> > > > > end if;=20 > >> > > >=20 > >> > > > that is a flopflip with clok enable; at every rising edge of fas= t_clk=20 > >> > > > D_in get "stored" and appears on Q_out, IF and only if clock_ena= ble is high > >> > > >=20 > >> > > > you busy signal goes to clock_enable > >> > >=20 > >> > > I understand. I'll try to work with that way of thinking. > >> > >=20 > >> > > If anyone's interested, here's my thinking on this type of circuit= . I think a construction like this would make more sense in hardware defin= ition source code: > >> > >=20 > >> > > // Declared in global space > >> > > BitObj goEnable; > >> > > goEnable.D_in =3D BUSY; > >> > > goEnable.set =3D @risingedge CLK; > >> >=20 > >> > D_in is you data input, BUSY should be a enable signal telling it to= ignore=20 > >> > the clock edges =20 > >> >=20 > >> > >=20 > >> > > // You can then reference this in your code anywhere: > >> > > Q_out =3D goEnable.out; > >>=20 > >> 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 i= s asserted at the start of a cycle, it should delay the entire cycle. > > > > Ok, I am throwing in the towel. You need to read some basic logic desi= 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. =20 >=20 > A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) w= orks: > http://electronics-course.com/d-flip-flop >=20 > Change the inputs on the symbol to see what happens. Or edit the timing > diagram by clicking and then hit 'simulate' >=20 > 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. 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. =20 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.=20 Rick C.=20 Tesla referral code +-+ https://ts.la/richard11209Article: 160816
On Wednesday, November 28, 2018 at 3:42:39 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote:
> > Any0 -- Logical NAND for Signal or Data (1 on any input 0)
> > All0 -- Logical NOR for Signal or Data (1 on all input 0)
>
> 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)
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
Article: 160817On Thursday, November 29, 2018 at 11:43:30 AM UTC-5, Rick C. Hodgin wrote: > On Wednesday, November 28, 2018 at 3:42:39 PM UTC-5, Rick C. Hodgin wrote: > > On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote: > > > Any0 -- Logical NAND for Signal or Data (1 on any input 0) > > > All0 -- Logical NOR for Signal or Data (1 on all input 0) > > > > 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) > > 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 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 +-+ https://ts.la/richard11209Article: 160818
On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.co= m wrote: > Most of us learn to walk before we learn to run. Give that a try. :)=20 You think you're funny, Rick C. You are not. > Do you have a simple question using terminology we all share and understa= nd?=20 I did that work in 2015. I recounted it from what I had saved at that time= in my git repository, and in my reviewing it on-the-spot after posting her= e I concluded incorrectly that it was wrong from that timeframe. As it tur= ns out, the way it was back then was correct, and I had thought things thro= ugh properly. I'm so tired of people telling me that I have to do things the way everyone= else does in order to be successful. The truth is you DO NOT if you're go= od enough, if you have enough vision and follow-through. Things that are f= undamental in nature's design rise up and speak for themselves in any proje= ct. There are a host of people moving forward all the time who come up wit= h new ways of doing old things better than the old ways. I've looked at the requirements of learning the tools that exist and I see = variances and issues in the way things are coded, things that could be done= away with, merged, rethought, refactored, improved upon, etc., and that's = what I plan to do with Logician, to bring in a more common base of natural = intuitive understanding from the way people think, and the way things are a= nd exist fundamentally, without having to learn the mechanisms established = in the industry previously where they don't make sense. Some of it is trul= y archaic and could use a fresh perspective. Without people willing to help me in THAT effort of looking at fundamentals= and rebuilding from the ground up for the future, I'll go it alone with sa= dness, and the lot of you can benefit from the product I ultimately produce= if you so desire. If not, no worries. No harm, no foul. I will NEVER EVER EVER say something negative to anyone in such a way as to= smash or diminish their hopes, dreams, or goals. Any goals which are trul= y off-the-charts ludicrous will have that fact revealed on the journey, and= for some people (possibly myself included), that's the ONLY way they'll EV= ER learn. But for the rest, beating someone down like that is horrific. To rise up with a negative voice and squelch someone in their heartfelt, en= thusiastic, honest, reaching-out, sincere efforts ... it's akin to the wors= t kind of criminal behavior one person can do to another. It damages thing= s on the inside which can never be undamaged. It cuts and produces scars t= hat remain for life, impacting countless other areas of their life for the = rest of their life. May God's light shine upon each of our souls the light of truth and hope, a= nd so brightly that all darkness is ended within each of us. --=20 Rick C. HodginArticle: 160819
On 29/11/2018 18:52, Rick C. Hodgin wrote: > On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote: >> Most of us learn to walk before we learn to run. Give that a try. :) > > You think you're funny, Rick C. You are not. > >> Do you have a simple question using terminology we all share and understand? > > I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly. > > I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways. > > I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective. > > Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul. > > I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific. > > To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life. > > May God's light shine upon each of our souls the light of truth and hope, and so brightly that all darkness is ended within each of us. > You have a very strange way of thanking people who give you sound advice. No one has suggested you don't learn to run - merely that you learn to walk first. No one has suggested that you should not dream, or reach for the stars - merely that jumping off a cliff is not a good way to learn to fly. Lashing out at people who try to help, and insulting them in such hyperbolic terms is not going to make your projects progress any faster. It is just going to mean fewer people to help you on your way. And for someone who says they will "NEVER EVER EVER say something negative to anyone", you really do write impressively strongly worded and highly negative posts sometimes. (And this one is not nearly as bad as some of the ones you have directed at me.)Article: 160820
On Thursday, November 29, 2018 at 12:52:16 PM UTC-5, Rick C. Hodgin wrote: > On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.= com wrote: > > Most of us learn to walk before we learn to run. Give that a try. :)= =20 >=20 > You think you're funny, Rick C. You are not. Not trying to be rude, I'm serious. You have gaping holes in your knowledg= e of digital logic design. If you don't know the significance of clock ena= bles and are just learning the faculties of logic gates there is no point r= eally in trying to teach you how to design a CPU.=20 > > Do you have a simple question using terminology we all share and unders= tand?=20 >=20 > I did that work in 2015. I recounted it from what I had saved at that ti= me in my git repository, and in my reviewing it on-the-spot after posting h= ere I concluded incorrectly that it was wrong from that timeframe. As it t= urns out, the way it was back then was correct, and I had thought things th= rough properly. I don't know what you are referring to here... at all. "it" has no meaning= to me unless you explain "it".=20 > I'm so tired of people telling me that I have to do things the way everyo= ne else does in order to be successful. The truth is you DO NOT if you're = good enough, if you have enough vision and follow-through. Things that are= fundamental in nature's design rise up and speak for themselves in any pro= ject. There are a host of people moving forward all the time who come up w= ith new ways of doing old things better than the old ways. You can do things any way you want. No one is telling you to do anything i= n a specific way. We don't understand what you are talking about because y= ou can't be bothered to learn the common terminology or any of the basic co= ncepts. If you want to learn it all on your own, inventing all the concept= s yourself and giving everything a name you invented, then why are you here= asking questions?=20 > I've looked at the requirements of learning the tools that exist and I se= e variances and issues in the way things are coded, things that could be do= ne away with, merged, rethought, refactored, improved upon, etc., and that'= s what I plan to do with Logician, to bring in a more common base of natura= l intuitive understanding from the way people think, and the way things are= and exist fundamentally, without having to learn the mechanisms establishe= d in the industry previously where they don't make sense. Some of it is tr= uly archaic and could use a fresh perspective. >=20 > Without people willing to help me in THAT effort of looking at fundamenta= ls and rebuilding from the ground up for the future, I'll go it alone with = sadness, and the lot of you can benefit from the product I ultimately produ= ce if you so desire. If not, no worries. No harm, no foul. No, I have no interest in reinventing things that aren't broken. I have wo= rk to do and know how to get my work done using the tools available. If yo= u want to design your own tools, obviously getting work done is secondary. = Regardless that isn't how you started this thread. You started by explain= ing what you were trying to do and how you were trying to do it and asked, = "Is there an easier / different way to do this?" All we have done is to tr= y to explain why using clock enables is an easier way to do what you were d= oing.=20 > I will NEVER EVER EVER say something negative to anyone in such a way as = to smash or diminish their hopes, dreams, or goals. Any goals which are tr= uly off-the-charts ludicrous will have that fact revealed on the journey, a= nd for some people (possibly myself included), that's the ONLY way they'll = EVER learn. But for the rest, beating someone down like that is horrific. >=20 > To rise up with a negative voice and squelch someone in their heartfelt, = enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the wo= rst kind of criminal behavior one person can do to another. It damages thi= ngs on the inside which can never be undamaged. It cuts and produces scars= that remain for life, impacting countless other areas of their life for th= e rest of their life. No one here has intentionally tried to be negative or to diminish your hope= s. What we have tried to do explain how you are on a long, painful road an= d that we can help you find an easier way if you will listen. If you want = to follow the rough road, that's your choice. I'm not making any judgement= s at all about your destination. That's all up to you.=20 If you want to discuss digital logic design, please ask questions. I'm not= interested in discussing how people are diminishing your hopes or anything= at all about god. This group is not about that. Sorry if you were hurt b= y anything I wrote.=20 Rick C.=20 Tesla referral code +++ https://ts.la/richard11209Article: 160821
torsdag den 29. november 2018 kl. 18.52.16 UTC+1 skrev Rick C. Hodgin: > On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.= com wrote: > > Most of us learn to walk before we learn to run. Give that a try. :)= =20 >=20 > You think you're funny, Rick C. You are not. >=20 > > Do you have a simple question using terminology we all share and unders= tand?=20 >=20 > I did that work in 2015. I recounted it from what I had saved at that ti= me in my git repository, and in my reviewing it on-the-spot after posting h= ere I concluded incorrectly that it was wrong from that timeframe. As it t= urns out, the way it was back then was correct, and I had thought things th= rough properly. >=20 > I'm so tired of people telling me that I have to do things the way everyo= ne else does in order to be successful. The truth is you DO NOT if you're = good enough, if you have enough vision and follow-through. Things that are= fundamental in nature's design rise up and speak for themselves in any pro= ject. There are a host of people moving forward all the time who come up w= ith new ways of doing old things better than the old ways. >=20 > I've looked at the requirements of learning the tools that exist and I se= e variances and issues in the way things are coded, things that could be do= ne away with, merged, rethought, refactored, improved upon, etc., and that'= s what I plan to do with Logician, to bring in a more common base of natura= l intuitive understanding from the way people think, and the way things are= and exist fundamentally, without having to learn the mechanisms establishe= d in the industry previously where they don't make sense. Some of it is tr= uly archaic and could use a fresh perspective. >=20 > Without people willing to help me in THAT effort of looking at fundamenta= ls and rebuilding from the ground up for the future, I'll go it alone with = sadness, and the lot of you can benefit from the product I ultimately produ= ce if you so desire. If not, no worries. No harm, no foul. >=20 > I will NEVER EVER EVER say something negative to anyone in such a way as = to smash or diminish their hopes, dreams, or goals. Any goals which are tr= uly off-the-charts ludicrous will have that fact revealed on the journey, a= nd for some people (possibly myself included), that's the ONLY way they'll = EVER learn. But for the rest, beating someone down like that is horrific. >=20 > To rise up with a negative voice and squelch someone in their heartfelt, = enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the wo= rst kind of criminal behavior one person can do to another. It damages thi= ngs on the inside which can never be undamaged. It cuts and produces scars= that remain for life, impacting countless other areas of their life for th= e rest of their life. >=20 > May God's light shine upon each of our souls the light of truth and hope,= and so brightly that all darkness is ended within each of us. >=20 I see why you "encounter resistance when I approach others with my thinking= "Article: 160822
On Thursday, November 29, 2018 at 7:02:04 PM UTC-5, lasselangwad...@gmail.c= om wrote: > torsdag den 29. november 2018 kl. 18.52.16 UTC+1 skrev Rick C. Hodgin: > > On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmai= l.com wrote: > > > Most of us learn to walk before we learn to run. Give that a try. := )=20 > >=20 > > You think you're funny, Rick C. You are not. > >=20 > > > Do you have a simple question using terminology we all share and unde= rstand?=20 > >=20 > > I did that work in 2015. I recounted it from what I had saved at that = time in my git repository, and in my reviewing it on-the-spot after posting= here I concluded incorrectly that it was wrong from that timeframe. As it= turns out, the way it was back then was correct, and I had thought things = through properly. > >=20 > > I'm so tired of people telling me that I have to do things the way ever= yone else does in order to be successful. The truth is you DO NOT if you'r= e good enough, if you have enough vision and follow-through. Things that a= re fundamental in nature's design rise up and speak for themselves in any p= roject. There are a host of people moving forward all the time who come up= with new ways of doing old things better than the old ways. > >=20 > > I've looked at the requirements of learning the tools that exist and I = see variances and issues in the way things are coded, things that could be = done away with, merged, rethought, refactored, improved upon, etc., and tha= t's what I plan to do with Logician, to bring in a more common base of natu= ral intuitive understanding from the way people think, and the way things a= re and exist fundamentally, without having to learn the mechanisms establis= hed in the industry previously where they don't make sense. Some of it is = truly archaic and could use a fresh perspective. > >=20 > > Without people willing to help me in THAT effort of looking at fundamen= tals and rebuilding from the ground up for the future, I'll go it alone wit= h sadness, and the lot of you can benefit from the product I ultimately pro= duce if you so desire. If not, no worries. No harm, no foul. > >=20 > > I will NEVER EVER EVER say something negative to anyone in such a way a= s to smash or diminish their hopes, dreams, or goals. Any goals which are = truly off-the-charts ludicrous will have that fact revealed on the journey,= and for some people (possibly myself included), that's the ONLY way they'l= l EVER learn. But for the rest, beating someone down like that is horrific= . > >=20 > > To rise up with a negative voice and squelch someone in their heartfelt= , enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the = worst kind of criminal behavior one person can do to another. It damages t= hings on the inside which can never be undamaged. It cuts and produces sca= rs that remain for life, impacting countless other areas of their life for = the rest of their life. > >=20 > > May God's light shine upon each of our souls the light of truth and hop= e, and so brightly that all darkness is ended within each of us. > >=20 >=20 >=20 > I see why you "encounter resistance when I approach others with my thinki= ng" I'm sorry this thread ended this way. I was hoping to help him make some p= rogress on his design and his understanding of how to design logic. But I = can't say I am surprised. He seems to have difficulties in understanding h= ow others think in general. So it shouldn't be a surprise that he had trou= ble understanding the concepts we tried to explain to him. I guess that is= also why he hasn't learned very much from all the many sources available o= n the web and in books.=20 I think that is the main reason why this group is relatively dead now. Mos= t people have found other, very easy ways to learn digital logic design. R= ich seems intent on literally reinventing the wheel in terms of digital log= ic design. Nothing he finds is good enough because it isn't the way he has= already started thinking without even trying to understand how others do i= t.=20 Rick C.=20 Tesla referral code ---- https://ts.la/richard11209Article: 160823
I appreciate the offer of help, Rick C. -- Rick C. HodginArticle: 160824
On 02/12/2018 01:18, gnuarm.deletethisbit@gmail.com wrote:
> I'm sorry this thread ended this way. I was hoping to help him make some progress on his design and his understanding of how to design logic. But I can't say I am surprised. He seems to have difficulties in understanding how others think in general. So it shouldn't be a surprise that he had trouble understanding the concepts we tried to explain to him. I guess that is also why he hasn't learned very much from all the many sources available on the web and in books.
>
Agreed. I have tried many times to help Rick (mostly in programming
groups, rather than this one). Sometimes it seems he learns a bit from
what I write, but sooner or later it ends with me or others telling him
he needs to learn more, or reduce the scope of his ambition, or re-think
the direction he is heading, and then we who help are declared to be
evil, negative influences, possessed by the devil (yes, apparently I am
possessed), or - as now - the worst sort of criminal.
> I think that is the main reason why this group is relatively dead now. Most people have found other, very easy ways to learn digital logic design. Rich seems intent on literally reinventing the wheel in terms of digital logic design. Nothing he finds is good enough because it isn't the way he has already started thinking without even trying to understand how others do it.
>
Most Usenet groups are relatively dead (at least, most technical and
useful ones). People have other ways to ask questions and share
knowledge. I can't comprehend why people ("the youth of today") seem to
prefer web-based forums, but they do.
Still, even a quite group like this gets interesting discussions
sometimes, although I am mostly a lurker here as I haven't done much
programmable logic design for a long time.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z