Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41540 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-08-26 00:53 -0400 |
| Last post | 2015-09-02 14:23 -0700 |
| Articles | 20 on this page of 59 — 16 participants |
Back to article view | Back to comp.lang.forth
Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 00:53 -0400
Re: Forth CPUs with NO Interrupts anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 08:51 +0000
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 08:50 -0400
Re: Forth CPUs with NO Interrupts "Elizabeth D. Rather" <erather@forth.com> - 2015-08-26 07:23 -1000
Re: Forth CPUs with NO Interrupts Mark Wills <markwills1970@gmail.com> - 2015-08-26 04:33 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 08:46 -0400
Re: Forth CPUs with NO Interrupts mhx@iae.nl - 2015-08-26 11:17 -0700
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-26 12:50 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 18:28 -0400
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-27 23:44 -0700
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-08-28 18:28 -0700
Re: Forth CPUs with NO Interrupts Walter Banks <walter@bytecraft.com> - 2015-08-26 11:41 -0400
Re: Forth CPUs with NO Interrupts Syd Rumpo <usenet@nononono.co.uk> - 2015-08-26 17:12 +0100
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-08-26 09:48 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 18:39 -0400
Re: Forth CPUs with NO Interrupts "Ala'a Alawi" <amalawi@gmail.com> - 2015-08-27 08:37 -0700
Re: Forth CPUs with NO Interrupts pbjtech@gmail.com - 2015-08-30 19:01 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-30 22:45 -0400
Re: Forth CPUs with NO Interrupts Reinhardt Behm <rbehm@hushmail.com> - 2015-08-31 11:09 +0800
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-30 20:06 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-30 23:20 -0400
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-02 14:14 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:02 -0400
Re: Forth CPUs with NO Interrupts Bob <bob@none.com> - 2015-08-31 20:49 -0400
Re: Forth CPUs with NO Interrupts Mark Wills <markwills1970@gmail.com> - 2015-09-01 01:39 -0700
Re: Forth CPUs with NO Interrupts dunno <dunno@dunno.dunno> - 2015-09-01 17:58 +0000
Re: Forth CPUs with NO Interrupts Bob <bob@none.com> - 2015-09-01 18:48 -0400
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-01 16:32 -0700
Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 01:38 +0200
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-01 22:09 -0400
Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 14:12 +0200
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 12:40 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 10:40 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 16:57 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 14:55 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:11 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 16:20 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 20:42 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 22:34 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-03 12:59 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-03 15:54 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-03 19:54 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-03 21:13 -0700
Re: Forth CPUs with NO Interrupts Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-09-04 09:48 +0100
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 08:49 -0700
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-04 11:15 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 14:32 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 11:36 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 17:46 -0400
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 11:47 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 09:20 -0700
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 12:52 -0400
Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 10:20 -0700
Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 23:35 +0200
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:09 -0400
Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 02:07 +0200
Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 20:49 -0400
Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 14:30 +0200
Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-02 14:23 -0700
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-08-30 23:20 -0400 |
| Message-ID | <ms0h3e$9vr$1@dont-email.me> |
| In reply to | #41621 |
On 8/30/2015 11:06 PM, hughaguilar96@gmail.com wrote: > On Sunday, August 30, 2015 at 7:01:59 PM UTC-7, pbj...@gmail.com > wrote: >> In fact cores are so much better than interrupts as they can be >> dedicated to the task at hand without distraction. For instance I >> am developing a 32 channel serial asynch with any mix of rx and tx >> (32 total) that is designed to work at 115,200 baud although the >> transmitters are quite happy working even at 1M baud, all in one >> core without any dedicated hardware UARTs etc. I've only spent less >> than a day on this and already the transmitter section is working >> very well without any jitter etc and now I am down to testing the >> receiver section while I get sidetracked and program one of the >> cores as a resident logic analyser. wOOt! >> >> Interrupts are great, that is if you only have a single core, which >> is not great at all these days. Multicore should not be thought of >> as parallel processing, as if even from the days of ILLIAC IV IIRC >> this was shown to be quite difficult/impossible to program. >> Multi-threading we understand though. Rather the cores are used IMO >> much as people are used within an organization, each specialized >> and looking after what they do best and everything runs smoothly. >> >> Interrupts? ah fooie! > > I agree that having more than one processor makes things easier. The > MiniForth had an 8032 on board with some 64MB of RAM (not a typo: > 64MB not 64KB). The 8032 had a UART built in, which the MiniForth > lacked, so the 8032 buffered the files from the desktop-computer and > then fed the data to the MiniForth through parallel I/O --- this way > the MiniForth could do the laser etching, but not have to store the > big files in memory (it had limited memory) --- the timing was pretty > precise on the motion-control, so you really can't have the processor > interrupted by a UART while it is in the middle of etching. > > I've been thinking about upgrading the FMITE so that it could be > multi-core. It is pretty small, so on a big FPGA it there would be > room for more than one of them. I would need semaphores so they don't > step on each other's toes when accessing common RAM. Can you describe > what is needed here? I think I need a primitive that can read and > modify a memory location in one step. It seems a bit odd to have the complexity of a CPU in an FPGA to handle the relatively simple task of motion control. Why not use a simpler CPU like the 8032 to control dedicated hardware for motion control? FPGAs are all about application dedicated hardware. Much easier to get the synchronization and precise control that way. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-02 14:14 -0700 |
| Message-ID | <3f2923f8-6fc1-472c-9eb9-f33f5bf5c4ab@googlegroups.com> |
| In reply to | #41623 |
On Sunday, August 30, 2015 at 8:20:59 PM UTC-7, rickman wrote: > On 8/30/2015 11:06 PM, hughaguilar96@gmail.com wrote: > > On Sunday, August 30, 2015 at 7:01:59 PM UTC-7, pbj...@gmail.com > > wrote: > >> Interrupts? ah fooie! > > > > I agree that having more than one processor makes things easier. The > > MiniForth had an 8032 on board with some 64MB of RAM (not a typo: > > 64MB not 64KB). The 8032 had a UART built in, which the MiniForth > > lacked, so the 8032 buffered the files from the desktop-computer and > > then fed the data to the MiniForth through parallel I/O --- this way > > the MiniForth could do the laser etching, but not have to store the > > big files in memory (it had limited memory) --- the timing was pretty > > precise on the motion-control, so you really can't have the processor > > interrupted by a UART while it is in the middle of etching. > It seems a bit odd to have the complexity of a CPU in an FPGA to handle > the relatively simple task of motion control. Why not use a simpler CPU > like the 8032 to control dedicated hardware for motion control? FPGAs > are all about application dedicated hardware. Much easier to get the > synchronization and precise control that way. Rickman obviously has no experience with motion-control. This is actually a difficult task. The tool has to accelerate and decelerate smoothly. The goal is to minimize harmonic resonance. There is a lot of math involved. A lot of motion-control programs solve this problem simply by putting a big delay (like 20 milliseconds) between every change of direction for the tool. This can't be done in a laser-etcher however. The tool (a mirror that directs the laser beam down onto the work surface) has to move at a steady speed so the laser will burn into the surface to a steady depth and width. If there were variations in speed at the joints where the lines change direction, then the laser would burn a blotch into the work surface at those joints. Testra used an 80c320 originally, and over time they converted all of the Forth code into assembly-language. It was too slow however (mostly because 16-bit multiplication was slow) --- this is why the MiniForth was invented --- to be a replacement for the 80c320 providing better speed (note that the 80c320 is more than three times faster than the 8032 that Rickman recommends). I don't actually have any experience with motion-control. The entire time that I worked at Testra, I never saw the source-code for the motion-control program, as that was highly proprietary. All I did was write MFX, the development system for the MiniForth --- the motion-control program is the only program that has ever been written in MFX, and I didn't see the source-code --- at least I admit that I don't know anything about motion-control however, which is a lot different than Rickman who describes motion-control as a "relatively simple task" and yet knows less about the subject than I do.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 18:02 -0400 |
| Message-ID | <ms7riu$49n$1@dont-email.me> |
| In reply to | #41670 |
On 9/2/2015 5:14 PM, hughaguilar96@gmail.com wrote: > On Sunday, August 30, 2015 at 8:20:59 PM UTC-7, rickman wrote: >> On 8/30/2015 11:06 PM, hughaguilar96@gmail.com wrote: >>> On Sunday, August 30, 2015 at 7:01:59 PM UTC-7, pbj...@gmail.com >>> wrote: >>>> Interrupts? ah fooie! >>> >>> I agree that having more than one processor makes things easier. The >>> MiniForth had an 8032 on board with some 64MB of RAM (not a typo: >>> 64MB not 64KB). The 8032 had a UART built in, which the MiniForth >>> lacked, so the 8032 buffered the files from the desktop-computer and >>> then fed the data to the MiniForth through parallel I/O --- this way >>> the MiniForth could do the laser etching, but not have to store the >>> big files in memory (it had limited memory) --- the timing was pretty >>> precise on the motion-control, so you really can't have the processor >>> interrupted by a UART while it is in the middle of etching. > >> It seems a bit odd to have the complexity of a CPU in an FPGA to handle >> the relatively simple task of motion control. Why not use a simpler CPU >> like the 8032 to control dedicated hardware for motion control? FPGAs >> are all about application dedicated hardware. Much easier to get the >> synchronization and precise control that way. > > Rickman obviously has no experience with motion-control. This is actually a difficult task. The tool has to accelerate and decelerate smoothly. The goal is to minimize harmonic resonance. There is a lot of math involved. A lot of motion-control programs solve this problem simply by putting a big delay (like 20 milliseconds) between every change of direction for the tool. This can't be done in a laser-etcher however. The tool (a mirror that directs the laser beam down onto the work surface) has to move at a steady speed so the laser will burn into the surface to a steady depth and width. If there were variations in speed at the joints where the lines change direction, then the laser would burn a blotch into the work surface at those joints. > > Testra used an 80c320 originally, and over time they converted all of the Forth code into assembly-language. It was too slow however (mostly because 16-bit multiplication was slow) --- this is why the MiniForth was invented --- to be a replacement for the 80c320 providing better speed (note that the 80c320 is more than three times faster than the 8032 that Rickman recommends). > > I don't actually have any experience with motion-control. The entire time that I worked at Testra, I never saw the source-code for the motion-control program, as that was highly proprietary. All I did was write MFX, the development system for the MiniForth --- the motion-control program is the only program that has ever been written in MFX, and I didn't see the source-code --- at least I admit that I don't know anything about motion-control however, which is a lot different than Rickman who describes motion-control as a "relatively simple task" and yet knows less about the subject than I do. No, I am not an expert in motion control. My point was about the division of labor between the fast processor and the slow. It seemed a bit odd to design a custom processor and then to program it in a custom language rather than to use an FPGA in the manner in which they work best. Of course I don't know the details of this application. That is why I *asked*. I think the answer I got was a more rude version of, "I don't know." Ok, I got it. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bob <bob@none.com> |
|---|---|
| Date | 2015-08-31 20:49 -0400 |
| Message-ID | <aF6Fx.7$tS.1@fx07.iad> |
| In reply to | #41621 |
On 08/30/2015 11:06 PM, hughaguilar96@gmail.com wrote: > I agree that having more than one processor makes things easier. The MiniForth had an 8032 on board with some 64MB of RAM (not a typo: 64MB not 64KB). The 8032 had a UART built in, which the MiniForth lacked, so the 8032 buffered the files from the desktop-computer and then fed the data to the MiniForth through parallel I/O --- this way the MiniForth could do the laser etching, but not have to store the big files in memory (it had limited memory) --- the timing was pretty precise on the motion-control, so you really can't have the processor interrupted by a UART while it is in the middle of etching. > > I've been thinking about upgrading the FMITE so that it could be multi-core. It is pretty small, so on a big FPGA it there would be room for more than one of them. I would need semaphores so they don't step on each other's toes when accessing common RAM. Can you describe what is needed here? I think I need a primitive that can read and modify a memory location in one step. > A primitive that can do three things in order in one step all at once is impossible. The 8086 instruction LOCK causes the cpu hardware to output on a pin from the start of read to end of write to tell the ram arbitrator not to let any other cpu interfere. That is equivalent to disable interrupts on a single cpu. A totally different approach to communication between processes is to use a linked list of small message buffers. One process uses the head pointer to take messages. The other process uses the tail pointer to send messages. Neither steps on the other's pointer. This works without disabling interrupts on a single cpu and it works without locking hardware on multiple cpus with shared ram. The ram needs to correctly complete one read or write at a time. It cannot mix bits from two simultaneous transfers. If you have that you have all you need. You may want more but you have what you need. odu_bob
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-09-01 01:39 -0700 |
| Message-ID | <c324b35d-cd31-4f70-8841-129b572e2726@googlegroups.com> |
| In reply to | #41630 |
On Tuesday, 1 September 2015 01:52:25 UTC+1, Bob wrote: > > A primitive that can do three things in order in one step all at > once is impossible. > Is it? What about the Forth primitive + ? In a VHDL implementation I have, that instruction: * Pops first operand off the stack (adjusting stack pointer) * Pops second operand off the stack (adjusting stack pointer) * Adds them * Pushes the result to the stack (adjusting the stack pointer) In a single clock cycle. That's at least 4 operations.
[toc] | [prev] | [next] | [standalone]
| From | dunno <dunno@dunno.dunno> |
|---|---|
| Date | 2015-09-01 17:58 +0000 |
| Message-ID | <ms4p04$km2$1@news.mixmin.net> |
| In reply to | #41634 |
Mark Wills <markwills1970@gmail.com> wrote: > On Tuesday, 1 September 2015 01:52:25 UTC+1, Bob wrote: >> >> A primitive that can do three things in order in one step all at >> once is impossible. >> > > Is it? What about the Forth primitive + ? > > In a VHDL implementation I have, that instruction: > > * Pops first operand off the stack (adjusting stack pointer) > * Pops second operand off the stack (adjusting stack pointer) > * Adds them > * Pushes the result to the stack (adjusting the stack pointer) > > In a single clock cycle. That's at least 4 operations. Why are you adjusting SP three times? It's needed only once. -- dunno
[toc] | [prev] | [next] | [standalone]
| From | Bob <bob@none.com> |
|---|---|
| Date | 2015-09-01 18:48 -0400 |
| Message-ID | <k_pFx.19798$Vn5.1113@fx26.iad> |
| In reply to | #41634 |
On 09/01/2015 04:39 AM, Mark Wills wrote: > On Tuesday, 1 September 2015 01:52:25 UTC+1, Bob wrote: >> >> A primitive that can do three things in order in one step all at >> once is impossible. >> > > Is it? What about the Forth primitive + ? > > In a VHDL implementation I have, that instruction: > > * Pops first operand off the stack (adjusting stack pointer) > * Pops second operand off the stack (adjusting stack pointer) > * Adds them > * Pushes the result to the stack (adjusting the stack pointer) > > In a single clock cycle. That's at least 4 operations. > All at ONCE? at one time read add and write all at ONE time? If they all happen at once there is no order, they happen at the same time. To organize communication between multiple processors the + primitive doesn't ensure CPU A won't read or write between the reads and writes of CPU B executing the + primitive. Several posts back the 8 core Propeller was mentioned then Hugh said he might need a primitive for multiple FMITEs. Again, a primitive that can be used to organize multiple CPUs to simultaneously read and write is impossible. It is a problem that is different from one CPU with an uninterruptible primitive. A different CPU is running and can execute reads and writes independent of the primitive read / write on the other CPU. The shared ram must ensure that a read or write happens correctly. Another read or write request that happens at the same time must be processed later or at the same time. At the same time is possible if the address is different, both are reads, or only one is a write. In the last case the read can correctly deliver the data from before or after the write. If both are writes the ram can retain either of the writes but mixing the bits would be bad. If your shared ram can't do that it gets much harder. That is a class of problem difficulty that I describe as "Knuth has a solution, don't bother to try to solve it again".
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-01 16:32 -0700 |
| Message-ID | <cdcba513-b05b-45c2-9efe-55994eedb6e8@googlegroups.com> |
| In reply to | #41651 |
On Tuesday, September 1, 2015 at 3:52:03 PM UTC-7, Bob wrote: > On 09/01/2015 04:39 AM, Mark Wills wrote: > > On Tuesday, 1 September 2015 01:52:25 UTC+1, Bob wrote: > >> > >> A primitive that can do three things in order in one step all at > >> once is impossible. > >> > > > > Is it? What about the Forth primitive + ? > > > > In a VHDL implementation I have, that instruction: > > > > * Pops first operand off the stack (adjusting stack pointer) > > * Pops second operand off the stack (adjusting stack pointer) > > * Adds them > > * Pushes the result to the stack (adjusting the stack pointer) > > > > In a single clock cycle. That's at least 4 operations. > > > All at ONCE? at one time read add and write all at ONE time? > If they all happen at once there is no order, they happen at > the same time. > > To organize communication between multiple processors the > + primitive doesn't ensure CPU A won't read or write between > the reads and writes of CPU B executing the + primitive. > > Several posts back the 8 core Propeller was mentioned then > Hugh said he might need a primitive for multiple FMITEs. > > Again, a primitive that can be used to organize multiple > CPUs to simultaneously read and write is impossible. It > is a problem that is different from one CPU with an > uninterruptible primitive. A different CPU is running > and can execute reads and writes independent of the > primitive read / write on the other CPU. I was assuming that the primitive would lock out the other processors from the common-memory during its execution --- I never said anything about simultaneous access to the common-memory --- that is obviously impossible. Anyway, I already figured out what my primitive needs to do, so never mind my question about what is needed --- now I wish that I hadn't asked.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-02 01:38 +0200 |
| Message-ID | <ms5cph$dda$1@dont-email.me> |
| In reply to | #41651 |
Bob wrote: >> In a VHDL implementation I have, that instruction: >> >> * Pops first operand off the stack (adjusting stack pointer) >> * Pops second operand off the stack (adjusting stack pointer) >> * Adds them >> * Pushes the result to the stack (adjusting the stack pointer) >> >> In a single clock cycle. That's at least 4 operations. >> > All at ONCE? at one time read add and write all at ONE time? > If they all happen at once there is no order, they happen at > the same time. I suppose that the stack pointer is in a register, and the VHDL compiler optimizes a sequence of +1+1-1 into +1. The stack itself might be out of registers, too, so there are two read and one write port to it. Can't be done in RAM. If the author kept TOS in a register, the rest can be done in a single ported RAM. That's what I do in my b16. But then, I know what I'm doing. I also only do one stack pointer update per instruction, removing an opportunity to show off how good it optimizes for the HDL compiler. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-01 22:09 -0400 |
| Message-ID | <ms5lks$v7g$1@dont-email.me> |
| In reply to | #41653 |
On 9/1/2015 7:38 PM, Bernd Paysan wrote: > Bob wrote: > >>> In a VHDL implementation I have, that instruction: >>> >>> * Pops first operand off the stack (adjusting stack pointer) >>> * Pops second operand off the stack (adjusting stack pointer) >>> * Adds them >>> * Pushes the result to the stack (adjusting the stack pointer) >>> >>> In a single clock cycle. That's at least 4 operations. >>> >> All at ONCE? at one time read add and write all at ONE time? >> If they all happen at once there is no order, they happen at >> the same time. > > I suppose that the stack pointer is in a register, and the VHDL compiler > optimizes a sequence of +1+1-1 into +1. The stack itself might be out of > registers, too, so there are two read and one write port to it. Can't be > done in RAM. What can't be done in RAM? Have you never heard of multiple port RAM? Ram is just registers connected to the outside world via multiplexors. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-02 14:12 +0200 |
| Message-ID | <ms6p0k$f5v$1@dont-email.me> |
| In reply to | #41654 |
rickman wrote: > What can't be done in RAM? Have you never heard of multiple port RAM? > Ram is just registers connected to the outside world via multiplexors. No, RAM is not registers connected to the outside world via multiplexers. That's a register file, RAM is way denser, and it's connected to the outside world via bit lines and sense amplifiers. There are two bit lines per bit, inverted to each other. You can do dual- ported RAM (by doubling the number of bit lines), but that means you can either read two entries in a go, or read one, and write one. That's what most FPGAs have inside; while you theoretically can have more ports (the more you have, the less dense is your RAM), you won't see that in an FPGA. So two reads, one write isn't possible in one cycle on an FPGA. Just put the top of stack into a register, and the number of ports to stack RAM can go down to one. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 12:40 -0400 |
| Message-ID | <ms78mf$hp1$1@dont-email.me> |
| In reply to | #41655 |
On 9/2/2015 8:12 AM, Bernd Paysan wrote: > rickman wrote: >> What can't be done in RAM? Have you never heard of multiple port RAM? >> Ram is just registers connected to the outside world via multiplexors. > > No, RAM is not registers connected to the outside world via multiplexers. > That's a register file, RAM is way denser, and it's connected to the outside > world via bit lines and sense amplifiers. > > There are two bit lines per bit, inverted to each other. You can do dual- > ported RAM (by doubling the number of bit lines), but that means you can > either read two entries in a go, or read one, and write one. That's what > most FPGAs have inside; while you theoretically can have more ports (the > more you have, the less dense is your RAM), you won't see that in an FPGA. > > So two reads, one write isn't possible in one cycle on an FPGA. Just put > the top of stack into a register, and the number of ports to stack RAM can > go down to one. You get hung up in meaningless distinctions while missing the point. "Bit lines" *are* multiplexors using a wire OR. You DO see dual port RAMs in FPGAs.... in fact it is hard to find RAMs that AREN'T dual port. By using two such RAMs in parallel you can have three ports implementing 2 reads and 1 write in any clock cycle. I have done this. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 10:40 -0700 |
| Message-ID | <2b10f494-9649-4a0a-8520-5d4a1187ac16@googlegroups.com> |
| In reply to | #41657 |
With the exception that blockram's are 'free' and don't take up resources, I use 16x16bit deep bi-directional shift-registers. They're generally cheaper and faster than using blockram but take, of course, more resources. All depends on what you need. With that, I only need two control bits: enable and direction. Additionally, all of these work in parallel so an Add basically does all of the logic in a single clock. No fiddling with stack pointers, adders and what not.. -Mux
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 16:57 -0400 |
| Message-ID | <ms7nos$hpi$1@dont-email.me> |
| In reply to | #41658 |
On 9/2/2015 1:40 PM, Mux wrote: > With the exception that blockram's are 'free' and don't take up > resources, I use 16x16bit deep bi-directional shift-registers. > They're generally cheaper and faster than using blockram but take, of > course, more resources. All depends on what you need. With that, I > only need two control bits: enable and direction. Additionally, all > of these work in parallel so an Add basically does all of the logic > in a single clock. No fiddling with stack pointers, adders and what > not.. I am speculating, but if you are using the Xilinx SRL (if that is the right name), thy are implemented as the LUT latches with counters to work as a shift register. They don't have full data paths to shift data between the latches and using counters saves power too. If you are implementing a proper shift register using FPGA registers, you are using a 2 to 1 mux on every bit of every register to get bi-directionality. BTW, blockrams are far from "free". They are just a different color of money. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 14:55 -0700 |
| Message-ID | <557e316e-d1eb-4dc9-bc34-243ddd7c1730@googlegroups.com> |
| In reply to | #41669 |
> I am speculating, but if you are using the Xilinx SRL (if that is the > right name), thy are implemented as the LUT latches with counters to > work as a shift register. They don't have full data paths to shift data > between the latches and using counters saves power too. If you are > implementing a proper shift register using FPGA registers, you are using > a 2 to 1 mux on every bit of every register to get bi-directionality. > Yeah, but since they're wedged inbetween latches / registers (for lack of a better word), the performance you get is higher. For a register file you need an NxM multiplexer which usually comes out slower. Add to that the fact that you now have need a bi-directional counter to address into that and your critical path has become even slower. > BTW, blockrams are far from "free". They are just a different color of > money. Oh, I'm sure :-) -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 18:11 -0400 |
| Message-ID | <ms7s40$5fk$2@dont-email.me> |
| In reply to | #41673 |
On 9/2/2015 5:55 PM, Mux wrote: >> I am speculating, but if you are using the Xilinx SRL (if that is the >> right name), thy are implemented as the LUT latches with counters to >> work as a shift register. They don't have full data paths to shift data >> between the latches and using counters saves power too. If you are >> implementing a proper shift register using FPGA registers, you are using >> a 2 to 1 mux on every bit of every register to get bi-directionality. >> > > Yeah, but since they're wedged inbetween latches / registers (for lack of a better word), the performance you get is higher. For a register file you need an NxM multiplexer which usually comes out slower. Add to that the fact that you now have need a bi-directional counter to address into that and your critical path has become even slower. And you only get them on Xilinx parts. Xilinx <> FPGA I don't optimize until I know I have an issue that requires optimization. Maybe the optimization is minimizing LUT usage? >> BTW, blockrams are far from "free". They are just a different color of >> money. > > Oh, I'm sure :-) > > -Y > -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 16:20 -0700 |
| Message-ID | <710fa208-7afe-4810-8121-9da26a0f3232@googlegroups.com> |
| In reply to | #41677 |
> And you only get them on Xilinx parts. Xilinx <> FPGA > > I don't optimize until I know I have an issue that requires > optimization. Maybe the optimization is minimizing LUT usage? Could be. I'm using altera and instantiating them individually. Either way, performance analysis comes out a few 10's of mhz higher. On Altera devices, it synthesizes to 1 LE/bit. -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 20:42 -0400 |
| Message-ID | <ms84v8$vod$3@dont-email.me> |
| In reply to | #41680 |
On 9/2/2015 7:20 PM, Mux wrote: >> And you only get them on Xilinx parts. Xilinx <> FPGA >> >> I don't optimize until I know I have an issue that requires >> optimization. Maybe the optimization is minimizing LUT usage? > > Could be. I'm using altera and instantiating them individually. Either way, performance analysis comes out a few 10's of mhz higher. On Altera devices, it synthesizes to 1 LE/bit. Something is wrong. Altera parts don't have shift registers built into their LEs. At least they didn't and I am pretty sure Xilinx has a patent on it, good for a few more years I expect... maybe not. Which part are you using? One of the latest and greatest? Or are you saying 1 LE/bit/sr depth? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 22:34 -0700 |
| Message-ID | <45f7f642-c80b-408d-8441-d90654639595@googlegroups.com> |
| In reply to | #41683 |
On Wednesday, September 2, 2015 at 5:43:03 PM UTC-7, rickman wrote: > On 9/2/2015 7:20 PM, Mux wrote: > >> And you only get them on Xilinx parts. Xilinx <> FPGA > >> > >> I don't optimize until I know I have an issue that requires > >> optimization. Maybe the optimization is minimizing LUT usage? > > > > Could be. I'm using altera and instantiating them individually. Either way, performance analysis comes out a few 10's of mhz higher. On Altera devices, it synthesizes to 1 LE/bit. > > Something is wrong. Altera parts don't have shift registers built into > their LEs. At least they didn't and I am pretty sure Xilinx has a > patent on it, good for a few more years I expect... maybe not. Which > part are you using? One of the latest and greatest? Or are you saying > 1 LE/bit/sr depth? > > -- > > Rick It's not built-in. I basically have an array of registers that does this for a pop: T <= reg[0]; reg[0] <= reg[1]; reg[1] <= reg[2]; ... reg[n] <= 16'd0; and the code below for a push. I'm actually using a loop construct so I don't have to write it out each time, but still.. T <= alu_result; reg[0] <= T; reg[1] <= reg[0]; ... All that this does is place a single 2-to-1 mux between each register based on the direction of shift, so it should (all) pretty much go down to routing. A 16x16 stack translates to 256 LE's on as low as an ancient EPC10k10 FPGA. -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-03 12:59 -0400 |
| Message-ID | <ms9u6c$v8d$1@dont-email.me> |
| In reply to | #41688 |
On 9/3/2015 1:34 AM, Mux wrote: > On Wednesday, September 2, 2015 at 5:43:03 PM UTC-7, rickman wrote: >> On 9/2/2015 7:20 PM, Mux wrote: >>>> And you only get them on Xilinx parts. Xilinx <> FPGA >>>> >>>> I don't optimize until I know I have an issue that requires >>>> optimization. Maybe the optimization is minimizing LUT usage? >>> >>> Could be. I'm using altera and instantiating them individually. >>> Either way, performance analysis comes out a few 10's of mhz >>> higher. On Altera devices, it synthesizes to 1 LE/bit. >> >> Something is wrong. Altera parts don't have shift registers built >> into their LEs. At least they didn't and I am pretty sure Xilinx >> has a patent on it, good for a few more years I expect... maybe >> not. Which part are you using? One of the latest and greatest? >> Or are you saying 1 LE/bit/sr depth? >> >> -- >> >> Rick > > It's not built-in. I basically have an array of registers that does > this for a pop: > > T <= reg[0]; reg[0] <= reg[1]; reg[1] <= reg[2]; .... reg[n] <= > 16'd0; > > and the code below for a push. I'm actually using a loop construct so > I don't have to write it out each time, but still.. > > T <= alu_result; reg[0] <= T; reg[1] <= reg[0]; .... > > All that this does is place a single 2-to-1 mux between each register > based on the direction of shift, so it should (all) pretty much go > down to routing. A 16x16 stack translates to 256 LE's on as low as an > ancient EPC10k10 FPGA. Yes and very inefficient in terms of logic utilization. A high price to pay for performance which may or may not pan out. I find the block RAMs are not in any of the critical timing paths of any CPU I've designed. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.lang.forth
csiph-web