Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29458 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2020-04-15 20:51 -0700 |
| Last post | 2020-04-20 18:02 +0200 |
| Articles | 20 on this page of 146 — 15 participants |
Back to article view | Back to comp.arch.embedded
Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-15 20:51 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 11:59 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-16 13:28 +0200
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 13:10 +0000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:16 +0100
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 22:01 +0000
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 17:13 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 18:10 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:37 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 22:08 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:02 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 10:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 15:44 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 15:23 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 18:15 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 17:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 15:06 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 16:08 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:13 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:24 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:00 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-20 14:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 23:55 +0100
Re: Custom CPU Designs Reinhardt Behm <rbehm@hushmail.com> - 2020-04-21 15:14 +0800
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-18 16:51 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 18:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:53 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 10:11 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-19 13:19 +0300
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 11:33 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:26 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:59 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:37 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:02 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:15 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 15:02 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:03 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:44 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:20 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:57 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 12:38 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:58 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:27 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:36 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 14:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 06:15 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:25 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 16:56 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 12:42 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:16 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:10 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:09 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:07 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 13:09 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 21:28 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-21 20:29 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-21 18:10 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 09:54 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 13:19 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 18:09 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:03 +0000
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:16 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 10:48 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 16:57 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:21 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 14:50 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:32 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:12 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 10:09 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:31 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:42 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-18 00:43 +0300
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 17:07 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:11 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 12:17 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 13:22 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 14:48 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 15:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:53 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 17:03 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 19:39 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 21:25 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:58 +0200
Re: Custom CPU Designs Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-04-21 19:41 +0300
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:01 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:21 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-19 20:53 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 14:47 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:11 +0100
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-19 18:31 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 20:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 07:46 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 00:33 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 11:01 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:44 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 19:57 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:56 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 16:34 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:57 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-21 15:20 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 08:26 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:09 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 15:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:28 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:24 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:18 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 11:45 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-23 17:47 +0200
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-21 15:35 -0700
Re: Custom CPU Designs Przemek Klosowski <przemek@tux.dot.org> - 2020-04-19 18:52 +0000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-20 22:59 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-21 10:23 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 03:47 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-22 09:26 +1000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-22 22:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 14:18 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-23 22:35 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:20 +0200
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 18:16 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:06 +0000
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 20:17 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:28 +0000
Re: Custom CPU Designs George Neuner <gneuner2@comcast.net> - 2020-04-23 04:59 -0400
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-20 17:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:58 +0200
Re: Custom CPU Designs pault.eg@googlemail.com - 2020-04-21 01:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 19:21 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 17:18 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 07:40 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 12:28 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 13:50 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 14:19 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:33 +0100
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 11:29 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 12:35 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 20:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 14:54 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 23:54 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:38 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:13 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 18:02 +0200
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-23 22:35 +0100 |
| Message-ID | <vrB*bkiQx@news.chiark.greenend.org.uk> |
| In reply to | #29602 |
Rick C <gnuarm.deletethisbit@gmail.com> wrote: > Yeah, but why exactly? Is the concern that there won't be future > updates/upgrades to the architecture? Tool support will wane? With the > various parties involved dropping like flies, it seems like it would be a > choice where no one would have an interest in bothering to collect > royalties. 1. If the IP situation is unclear, companies may hold back in case someone litigious ends up as the owner of the IP (see SCO) 2. It appears there is only one remaining Linux maintainer, LLVM has no maintenance, FreeBSD is likely to drop MIPS in 2022. Most end users are unlikely to put in the effort to keep the toolchains current. Theo
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-21 18:20 +0200 |
| Message-ID | <r7n6fm$j2$1@dont-email.me> |
| In reply to | #29553 |
On 21/04/2020 02:23, Clifford Heath wrote: > On 21/4/20 10:01 am, Rick C wrote: >> On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote: >>> On 20/4/20 4:52 am, Przemek Klosowski wrote: >>>> On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: >>>> >>>>> Grant Edwards <invalid@invalid.invalid> writes: >>>>>> Definitely. The M-class parts are so cheap, there's not much point in >>>>>> thinking about doing it in an FPGA. >>>>> >>>>> Well I think the idea is already you have other stuff in the FPGA, so >>>>> you save a package and some communications by dropping in a softcore >>>>> rather than using an external MCU. I'm surprised that only high end >>>>> FPGA's currently have hard MCU's already there. Just like they >>>>> have DSP >>>>> blocks, ram blocks, SERDES, etc., they might as well put in some CPU >>>>> blocks. >>>> >>>> Maybe Risc-V will catch on. The design is FOSS, as is the toolchain >>>> (GDB >>>> and LLVM have Risc-V backends already for a while), and the simple >>>> versions take very few gates. >>>> https://github.com/SpinalHDL/VexRiscv >>>> https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ >>>> >>> >>> There's a lot of push in the direction of the Power architecture. What >>> does that look like in FPGA? >>> >>> CH >> >> Do you mean the Power PC? That was the hard IP used in the very old >> and possibly obsolete Virtex II Pro devices. >> >> Why do they have to use such goofy names like "Pro" or "Polarfire". >> Do they really think that sells even one frigging chip? I would be so >> much more inclined to dig through their information if they just had >> decent names that give you some idea of the technical details >> including the heritage. > > Hah! I hear you. :) > > Yes, I mean PowerPC, specifically OpenPoWER: > <https://en.wikipedia.org/wiki/OpenPOWER_Foundation> > > A friend is a fan. Me, I haven't read much about it. > I haven't seem much of PowerPC in recent times. For a while they were popular for high-end microcontrollers, especially in the automotive industry, but that seems to be fading - since NXP took over Freescale, I think the PPC lines are dying out in favour of more ARM lines. Power, which is a different beast (with shared ancestry and a certain degree of compatibility), is alive and reasonably well - it's a popular choice for really big iron. I've seen benchmarks showing Power9 chips giving more bitcoins per MWt than dedicated miner ASICs, if you are into that sort of thing. I can't see anyone embedding a Power core in an FPGA...
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2020-04-22 18:16 +0300 |
| Message-ID | <r7pn4u$ur3$1@dont-email.me> |
| In reply to | #29572 |
On 4/21/2020 19:20, David Brown wrote: > On 21/04/2020 02:23, Clifford Heath wrote: >> On 21/4/20 10:01 am, Rick C wrote: >>> On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote: >>>> On 20/4/20 4:52 am, Przemek Klosowski wrote: >>>>> On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: >>>>> >>>>>> Grant Edwards <invalid@invalid.invalid> writes: >>>>>>> Definitely. The M-class parts are so cheap, there's not much >>>>>>> point in >>>>>>> thinking about doing it in an FPGA. >>>>>> >>>>>> Well I think the idea is already you have other stuff in the FPGA, so >>>>>> you save a package and some communications by dropping in a softcore >>>>>> rather than using an external MCU. I'm surprised that only high end >>>>>> FPGA's currently have hard MCU's already there. Just like they >>>>>> have DSP >>>>>> blocks, ram blocks, SERDES, etc., they might as well put in some CPU >>>>>> blocks. >>>>> >>>>> Maybe Risc-V will catch on. The design is FOSS, as is the toolchain >>>>> (GDB >>>>> and LLVM have Risc-V backends already for a while), and the simple >>>>> versions take very few gates. >>>>> https://github.com/SpinalHDL/VexRiscv >>>>> https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ >>>>> >>>> >>>> There's a lot of push in the direction of the Power architecture. What >>>> does that look like in FPGA? >>>> >>>> CH >>> >>> Do you mean the Power PC? That was the hard IP used in the very old >>> and possibly obsolete Virtex II Pro devices. >>> >>> Why do they have to use such goofy names like "Pro" or "Polarfire". >>> Do they really think that sells even one frigging chip? I would be >>> so much more inclined to dig through their information if they just >>> had decent names that give you some idea of the technical details >>> including the heritage. >> >> Hah! I hear you. :) >> >> Yes, I mean PowerPC, specifically OpenPoWER: >> <https://en.wikipedia.org/wiki/OpenPOWER_Foundation> >> >> A friend is a fan. Me, I haven't read much about it. >> > > I haven't seem much of PowerPC in recent times. For a while they were > popular for high-end microcontrollers, especially in the automotive > industry, but that seems to be fading - since NXP took over Freescale, I > think the PPC lines are dying out in favour of more ARM lines. > > Power, which is a different beast (with shared ancestry and a certain > degree of compatibility), is alive and reasonably well - it's a popular > choice for really big iron. I've seen benchmarks showing Power9 chips > giving more bitcoins per MWt than dedicated miner ASICs, if you are into > that sort of thing. > > I can't see anyone embedding a Power core in an FPGA... > > > Actually what used to be called "PowerPC" is today called "Power Architecture". Some parts from Freescale have been called either over time. NXP support and make the power architecture line (and yes, they do call it that), their top of the line parts are still these (QORIQ, that name did not go away as it might have to....). There is difference from core to core of course but this has always been the case last 25+ years. The initial "power" by IBM from the 80-s was different - not that much but more than they differ nowadays. It can be transparent for user level code on which core it runs, well, 32 vs. 64 bits can of course be more challenging. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-22 17:06 +0000 |
| Message-ID | <r7ptiq$h8v$3@reader2.panix.com> |
| In reply to | #29592 |
On 2020-04-22, Dimiter_Popoff <dp@tgi-sci.com> wrote: > NXP support and make the power architecture line (and yes, they do call > it that), their top of the line parts are still these (QORIQ, that name > did not go away as it might have to....). QoriQ? Wow. That name is stunningly, amzaingly bad. Do Silicon vendors send people to some specialized school where they learn to come up with the most awfult product line names possible? -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2020-04-22 20:17 +0300 |
| Message-ID | <r7pu76$jij$1@dont-email.me> |
| In reply to | #29595 |
On 4/22/2020 20:06, Grant Edwards wrote: > On 2020-04-22, Dimiter_Popoff <dp@tgi-sci.com> wrote: > >> NXP support and make the power architecture line (and yes, they do call >> it that), their top of the line parts are still these (QORIQ, that name >> did not go away as it might have to....). > > QoriQ? > > Wow. That name is stunningly, amzaingly bad. Do Silicon vendors send > people to some specialized school where they learn to come up with the > most awfult product line names possible? > > -- > Grant > They had that "digital DNA" before, not much better :-). Someone in their marketing may think they are in the business of selling soap or chocolate... Of course it does not matter much, how many of us would pay attention to the marketing name when choosing a platform - and their products are really good. OTOH I am not sure to what extent the likes of us here have much to say in big corporations when it comes to platform selection so things like that may have cost them.... or made them profit, I would not bet much on which of the two. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-22 17:28 +0000 |
| Message-ID | <r7purq$75h$1@reader2.panix.com> |
| In reply to | #29596 |
On 2020-04-22, Dimiter_Popoff <dp@tgi-sci.com> wrote: > On 4/22/2020 20:06, Grant Edwards wrote: > >> QoriQ? >> >> Wow. That name is stunningly, amzaingly bad. [...] > > They had that "digital DNA" before, not much better :-). I remember being at an Embedded System Conference during the "Digital DNA" campaign and seeing that phrase on T-shirts, tote-bags, ID badge lanyards, etc. I even sat through a "Digital DNA" video presentation at one point during the conference. Neither I nor anybody I talked to had the faintest idea what "Digital DNA" was supposed to mean or whether it referred to anything concrete or not. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2020-04-23 04:59 -0400 |
| Message-ID | <d4m2af1232cigah4hgvfrftimfvselm9at@4ax.com> |
| In reply to | #29595 |
On Wed, 22 Apr 2020 17:06:35 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote: >On 2020-04-22, Dimiter_Popoff <dp@tgi-sci.com> wrote: > >> NXP support and make the power architecture line (and yes, they do call >> it that), their top of the line parts are still these (QORIQ, that name >> did not go away as it might have to....). > >QoriQ? > >Wow. That name is stunningly, amzaingly bad. Do Silicon vendors send >people to some specialized school where they learn to come up with the >most awfult product line names possible? They get names from the same source as do pharmaceuticals.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2020-04-20 17:27 -0700 |
| Message-ID | <90f0648a-ea96-4878-b38b-15feb70b3bbe@googlegroups.com> |
| In reply to | #29552 |
On Monday, April 20, 2020 at 7:01:52 PM UTC-5, Rick C wrote: > On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote: > > On 20/4/20 4:52 am, Przemek Klosowski wrote: > > > On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: > > > > > >> Grant Edwards <invalid@invalid.invalid> writes: > > >>> Definitely. The M-class parts are so cheap, there's not much point in > > >>> thinking about doing it in an FPGA. > > >> > > >> Well I think the idea is already you have other stuff in the FPGA, so > > >> you save a package and some communications by dropping in a softcore > > >> rather than using an external MCU. I'm surprised that only high end > > >> FPGA's currently have hard MCU's already there. Just like they have DSP > > >> blocks, ram blocks, SERDES, etc., they might as well put in some CPU > > >> blocks. > > > > > > Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB > > > and LLVM have Risc-V backends already for a while), and the simple > > > versions take very few gates. > > > https://github.com/SpinalHDL/VexRiscv > > > https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ > > > > > > > There's a lot of push in the direction of the Power architecture. What > > does that look like in FPGA? > > > > CH > > Do you mean the Power PC? That was the hard IP used in the very old and possibly obsolete Virtex II Pro devices. > > Why do they have to use such goofy names like "Pro" or "Polarfire". Do they really think that sells even one frigging chip? I would be so much more inclined to dig through their information if they just had decent names that give you some idea of the technical details including the heritage. > > -- > > Rick C. > > +--- Get 1,000 miles of free Supercharging > +--- Tesla referral code - https://ts.la/richard11209 |>Do you mean the Power PC? That was the hard IP used in the very old and |> possibly obsolete Virtex II Pro devices. Also on Virtex-4 (90nm) and Virtex-5 (65nm & six input LUTs) |>goofy names like "Pro" or "Polarfire" in an industry full of hyperbola why exclude a niche player: "28nm non-volatile process yields very low static power"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 17:58 +0200 |
| Message-ID | <r7kgrt$fam$2@dont-email.me> |
| In reply to | #29514 |
On 19/04/2020 20:52, Przemek Klosowski wrote: > On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: > >> Grant Edwards <invalid@invalid.invalid> writes: >>> Definitely. The M-class parts are so cheap, there's not much point in >>> thinking about doing it in an FPGA. >> >> Well I think the idea is already you have other stuff in the FPGA, so >> you save a package and some communications by dropping in a softcore >> rather than using an external MCU. I'm surprised that only high end >> FPGA's currently have hard MCU's already there. Just like they have DSP >> blocks, ram blocks, SERDES, etc., they might as well put in some CPU >> blocks. > > Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB > and LLVM have Risc-V backends already for a while), and the simple > versions take very few gates. > https://github.com/SpinalHDL/VexRiscv > https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ > Has anyone here tried SpinalHDL ? I had a look at it, and it seems very appealing.
[toc] | [prev] | [next] | [standalone]
| From | pault.eg@googlemail.com |
|---|---|
| Date | 2020-04-21 01:00 -0700 |
| Message-ID | <eb5506ad-87ed-4993-8651-cbe2400ac807@googlegroups.com> |
| In reply to | #29545 |
On Monday, April 20, 2020 at 4:58:57 PM UTC+1, David Brown wrote: > On 19/04/2020 20:52, Przemek Klosowski wrote: > > On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: > > > >> Grant Edwards <invalid@invalid.invalid> writes: > >>> Definitely. The M-class parts are so cheap, there's not much point in > >>> thinking about doing it in an FPGA. > >> > >> Well I think the idea is already you have other stuff in the FPGA, so > >> you save a package and some communications by dropping in a softcore > >> rather than using an external MCU. I'm surprised that only high end > >> FPGA's currently have hard MCU's already there. Just like they have DSP > >> blocks, ram blocks, SERDES, etc., they might as well put in some CPU > >> blocks. > > > > Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB > > and LLVM have Risc-V backends already for a while), and the simple > > versions take very few gates. > > https://github.com/SpinalHDL/VexRiscv > > https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ > > > > Has anyone here tried SpinalHDL ? I had a look at it, and it seems very > appealing. Haven't tried it, but did follow the link and looked at the code. I thought it was interesting in that registers are explicit rather than using a rising_edge(clk) if statement. I followed some of the links on https://github.com/riscv/riscv-cores-list and found Chisel to be similar to SpinalHDL. I did a quick compare of UART TX code for Spinal and Chisel from here https://spinalhdl.github.io/SpinalDoc/spinal/examples/uart/ and here https://github.com/nyuichi/chisel-uart/blob/master/src/main/scala/Uart.scala. Overall I didn't see anything compelling compared to VHDL, in that admittedly very limited quick look :) The Spinal website says one of it's advantages is "Reduce code size - By a high factor, especially for wiring. This enables you to have a better overview of your code base, increase your productivity and create fewer headaches.". That looks to be a false statement (I didn't look at the wiring). Maybe there is something in the other stated advantages but I only looked at the above.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-21 19:21 +0200 |
| Message-ID | <r7na3d$r4k$1@dont-email.me> |
| In reply to | #29560 |
On 21/04/2020 10:00, pault.eg@googlemail.com wrote: > On Monday, April 20, 2020 at 4:58:57 PM UTC+1, David Brown wrote: >> On 19/04/2020 20:52, Przemek Klosowski wrote: >>> On Thu, 16 Apr 2020 17:13:41 -0700, Paul Rubin wrote: >>> >>>> Grant Edwards <invalid@invalid.invalid> writes: >>>>> Definitely. The M-class parts are so cheap, there's not much point in >>>>> thinking about doing it in an FPGA. >>>> >>>> Well I think the idea is already you have other stuff in the FPGA, so >>>> you save a package and some communications by dropping in a softcore >>>> rather than using an external MCU. I'm surprised that only high end >>>> FPGA's currently have hard MCU's already there. Just like they have DSP >>>> blocks, ram blocks, SERDES, etc., they might as well put in some CPU >>>> blocks. >>> >>> Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB >>> and LLVM have Risc-V backends already for a while), and the simple >>> versions take very few gates. >>> https://github.com/SpinalHDL/VexRiscv >>> https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/ >>> >> >> Has anyone here tried SpinalHDL ? I had a look at it, and it seems very >> appealing. > > Haven't tried it, but did follow the link and looked at the code. > > I thought it was interesting in that registers are explicit rather than using a rising_edge(clk) if statement. > > I followed some of the links on https://github.com/riscv/riscv-cores-list and found Chisel to be similar to SpinalHDL. > > I did a quick compare of UART TX code for Spinal and Chisel from here > https://spinalhdl.github.io/SpinalDoc/spinal/examples/uart/ and here > https://github.com/nyuichi/chisel-uart/blob/master/src/main/scala/Uart.scala. > > Overall I didn't see anything compelling compared to VHDL, in that admittedly very limited quick look :) If you want to read more: <https://cdn.rawgit.com/SpinalHDL/SpinalDoc/5d3d56b5/presentation/en/workshop/taste.pdf> <https://spinalhdl.github.io/SpinalDoc-RTD/SpinalHDL/miscelenea/regular_hdl.html#regular-hdl> > > The Spinal website says one of it's advantages is "Reduce code size - By a high > factor, especially for wiring. This enables you to have a better overview of > your code base, increase your productivity and create fewer headaches.". > That looks to be a false statement (I didn't look at the wiring). Maybe there > is something in the other stated advantages but I only looked at the above. > I haven't used SpinalHDL at all - I haven't had the chance to do much programmable logic for many years. But a /long/ time ago, I did some using Confluence which was a functional programming language for hardware design. For testing, I remember writing a simple PWM module with an Avalon bus slave (this was on a NIOS soft processor system). It was designed to match the same specs as an example from Altera, available in both Verilog and/or VHDL. My Confluence design ended up roughly similar in terms of logic area and speed, but it had about a tenth of the lines of source code - most of which was a generic bus and register interface that could be re-used unchanged for other bus slaves.
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-17 17:18 +0100 |
| Message-ID | <vrB*1wNPx@news.chiark.greenend.org.uk> |
| In reply to | #29468 |
Grant Edwards <invalid@invalid.invalid> wrote: > Once I got a UART working so I count print messages, I just gave up on > the JTAG BS. Another interesting quirk was that the Altera USB JTAG > interface only worked right with a few specific models of powered USB > hubs. I've spent months working around such problems :( We have an application that pushes gigabytes through JTAG UARTs and have learnt all about it... There's a pile of specific issues: - the USB 1.1 JTAG is an FT245 chip which basically bitbangs JTAG; it sends a byte containing 4 bits for the 4 JTAG wires. The software is literally saying "clock high, clock low, clock high, clock low" etc. Timing of that is not reliable. Newer development boards have a USB 2.0 programmer where things are a bit better here, but it's still bitbanging. - being USB 1.1, if you have a cheap USB 2.0 hub it may only support USB SST which means all USB 1.1 peripherals share 12Mbps of bandwidth. In our case we have 16 FPGAs all trying to chat using that shared 12Mbps bandwidth. Starvation occurs and nobody makes any progress. A better hub with MST will allow multiple 12Mbps streams to share the 480Mbps USB 2.0 bandwidth. Unfortunately when you buy a hub this is never advertised or explained. - The software daemon that generates the bitbanging data is called jtagd and it's single threaded. It can max out a CPU core bitbanging, and that can lead to unreliability. I had an Atom where it was unusable. I now install i7s in servers with FPGAs, purely to push bits down the JTAG wire. - To parallelise downloads to multiple FPGAs, I've written some horrible containerisation scripts that lie to each jtagd there's only one FPGA in tte system. Then I can launch 16 jtagds and use all 16 cores in my system to push traffic through the JTAG UARTs - Did I mention that programming an FPGA takes about 700MB? So I need to fit at least 8GB of RAM to avoid memory starvation when doing parallel programming (if the system swaps the bitbanging stalls and the FPGA programming fails) - there's some troubles with jtagd and libudev.so.0 - if you don't have it things seem to work but get unreliable. I just symlink libudev.so.1 on Ubuntu and it seems to fix it. - the register-level interface of the JTAG UART isn't able to read the state of the input FIFO without also dequeuing the data on it. Writing reliable device drivers is almost impossible. I have a version that wraps the UART in a 16550 register interface to avoid this problem. - if the FPGA is failing timing, the producer/consumer of the UART can break in interesting ways, which look a lot like there's some problem with the USB hub or similar. It's a very precarious pile of hardware and software that falls over in numerous ways if pushed at all hard :( Theo [adding comp.arch.fpga since this is relevant to those folks]
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-16 07:40 -0700 |
| Message-ID | <cff27757-6124-4094-a015-f85a83fe93b8@googlegroups.com> |
| In reply to | #29459 |
On Thursday, April 16, 2020 at 6:59:29 AM UTC-4, Theo wrote: > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > In the Forth language group there are occasional discussions of custom > > processors. This is mostly because a simple stack processor can be > > designed to be implemented in an FPGA very easily, taking little resources > > and running at a good speed. Such a stack processor is a good target for > > Forth. > > > > I know there are many other types of CPU designs which are implemented in > > FPGAs. I'm wondering how often these are used by the typical embedded > > developer? > > It's not uncommon when you have an FPGA doing some task to need a processor > in there to manage it - for example to handle error conditions or to report > status over some software-friendly interface like I2C, or classical printf > debugging on a UART. > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > legacy (toolchains aren't that great, etc), although designed to be fairly > small. There's increasing interest in small 32-bit RISC-V cores for this > niche, since the toolchain is improving and the licensing conditions more > liberal (RISC-V itself doesn't design cores, but lots of others - including > ourselves - have made open source cores to the RISC-V specification). Someone showed me that RISC-V can be a small solution, but at that size it isn't fast. So the size performance tradeoff isn't so great. Stack processors tend to be very lean and speed effective without pipelining. I know my processor was designed to run 1 instruction per clock cycle on all instructions. > I don't see that Forth has much to speak to this niche, given these cores > are largely offloading work that's fiddly to do in hardware and people just > want to write some (usually) C to mop up the loose ends. I can't see what > Forth would gain them for this. Not sure what you mean about Forth and "speaking". Forth is a natural language for a stack based processor. Often there is a 1 to 1 mapping of instructions to language words. It is also very easy to retarget to new modifications to a processor design. > If you're talking using these processors as a compute overlay for FPGAs, a > different thing entirely, I'd suggest that a stack processor is likely not > very efficient in terms of throughput. Although I don't have a cite to back > that up. I recall someone had a very large compendium of soft core processors with size and speed measurements with a calculation of something like IPS/LUT. It was amazing what some designs could achieve. I wish I knew where to find that now. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2020-04-16 12:28 -0700 |
| Message-ID | <d1aea0fb-d970-4ddd-aac2-dcabaf3d672f@googlegroups.com> |
| In reply to | #29462 |
On Thursday, April 16, 2020 at 9:40:55 AM UTC-5, Rick C wrote: > On Thursday, April 16, 2020 at 6:59:29 AM UTC-4, Theo wrote: > > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > > In the Forth language group there are occasional discussions of custom > > > processors. This is mostly because a simple stack processor can be > > > designed to be implemented in an FPGA very easily, taking little resources > > > and running at a good speed. Such a stack processor is a good target for > > > Forth. > > > > > > I know there are many other types of CPU designs which are implemented in > > > FPGAs. I'm wondering how often these are used by the typical embedded > > > developer? > > > > It's not uncommon when you have an FPGA doing some task to need a processor > > in there to manage it - for example to handle error conditions or to report > > status over some software-friendly interface like I2C, or classical printf > > debugging on a UART. > > > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > > legacy (toolchains aren't that great, etc), although designed to be fairly > > small. There's increasing interest in small 32-bit RISC-V cores for this > > niche, since the toolchain is improving and the licensing conditions more > > liberal (RISC-V itself doesn't design cores, but lots of others - including > > ourselves - have made open source cores to the RISC-V specification). > > Someone showed me that RISC-V can be a small solution, but at that size it isn't fast. So the size performance tradeoff isn't so great. Stack processors tend to be very lean and speed effective without pipelining. I know my processor was designed to run 1 instruction per clock cycle on all instructions. > > > > I don't see that Forth has much to speak to this niche, given these cores > > are largely offloading work that's fiddly to do in hardware and people just > > want to write some (usually) C to mop up the loose ends. I can't see what > > Forth would gain them for this. > > Not sure what you mean about Forth and "speaking". Forth is a natural language for a stack based processor. Often there is a 1 to 1 mapping of instructions to language words. It is also very easy to retarget to new modifications to a processor design. > > > > If you're talking using these processors as a compute overlay for FPGAs, a > > different thing entirely, I'd suggest that a stack processor is likely not > > very efficient in terms of throughput. Although I don't have a cite to back > > that up. > > I recall someone had a very large compendium of soft core processors with size and speed measurements with a calculation of something like IPS/LUT. It was amazing what some designs could achieve. I wish I knew where to find that now. > > -- > > Rick C. > > + Get 1,000 miles of free Supercharging > + Tesla referral code - https://ts.la/richard11209 |>very large compendium of soft core processors https://opencores.org/projects/up_core_list/summary Several legacy processors are listed: https://opencores.org/projects/up_core_list/downloads uP_core_list_by_style-clone190221.pdf Also look into MISTer as it supports several legacy systems. None are competitive speed wise with high performance uP. With LUTs costing less than $0.001 each some soft core uPs are inexpensive, free if you have unused LUTs and block RAMs. For debug, changing block RAM contents is much faster than rerunning the FPGA design.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-16 13:50 -0700 |
| Message-ID | <bb894d7d-ae82-4ea7-b518-1c9105ee73da@googlegroups.com> |
| In reply to | #29463 |
On Thursday, April 16, 2020 at 3:28:22 PM UTC-4, jim.br...@ieee.org wrote: > On Thursday, April 16, 2020 at 9:40:55 AM UTC-5, Rick C wrote: > > On Thursday, April 16, 2020 at 6:59:29 AM UTC-4, Theo wrote: > > > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > > > In the Forth language group there are occasional discussions of custom > > > > processors. This is mostly because a simple stack processor can be > > > > designed to be implemented in an FPGA very easily, taking little resources > > > > and running at a good speed. Such a stack processor is a good target for > > > > Forth. > > > > > > > > I know there are many other types of CPU designs which are implemented in > > > > FPGAs. I'm wondering how often these are used by the typical embedded > > > > developer? > > > > > > It's not uncommon when you have an FPGA doing some task to need a processor > > > in there to manage it - for example to handle error conditions or to report > > > status over some software-friendly interface like I2C, or classical printf > > > debugging on a UART. > > > > > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > > > legacy (toolchains aren't that great, etc), although designed to be fairly > > > small. There's increasing interest in small 32-bit RISC-V cores for this > > > niche, since the toolchain is improving and the licensing conditions more > > > liberal (RISC-V itself doesn't design cores, but lots of others - including > > > ourselves - have made open source cores to the RISC-V specification). > > > > Someone showed me that RISC-V can be a small solution, but at that size it isn't fast. So the size performance tradeoff isn't so great. Stack processors tend to be very lean and speed effective without pipelining. I know my processor was designed to run 1 instruction per clock cycle on all instructions. > > > > > > > I don't see that Forth has much to speak to this niche, given these cores > > > are largely offloading work that's fiddly to do in hardware and people just > > > want to write some (usually) C to mop up the loose ends. I can't see what > > > Forth would gain them for this. > > > > Not sure what you mean about Forth and "speaking". Forth is a natural language for a stack based processor. Often there is a 1 to 1 mapping of instructions to language words. It is also very easy to retarget to new modifications to a processor design. > > > > > > > If you're talking using these processors as a compute overlay for FPGAs, a > > > different thing entirely, I'd suggest that a stack processor is likely not > > > very efficient in terms of throughput. Although I don't have a cite to back > > > that up. > > > > I recall someone had a very large compendium of soft core processors with size and speed measurements with a calculation of something like IPS/LUT. It was amazing what some designs could achieve. I wish I knew where to find that now. > > > > -- > > > > Rick C. > > > > + Get 1,000 miles of free Supercharging > > + Tesla referral code - https://ts.la/richard11209 > > |>very large compendium of soft core processors > https://opencores.org/projects/up_core_list/summary > > Several legacy processors are listed: > https://opencores.org/projects/up_core_list/downloads > uP_core_list_by_style-clone190221.pdf > > Also look into MISTer as it supports several legacy systems. > None are competitive speed wise with high performance uP. > > With LUTs costing less than $0.001 each some soft core uPs are inexpensive, free if you have unused LUTs and block RAMs. > For debug, changing block RAM contents is much faster than rerunning the FPGA design. I don't think the issue is very often $ with a soft core. At least for me it's about board space and integration with the other FPGA functions. Looks like I was mistaken about the speed/size of the RISC-V core. However... it appears to have been hand optimized if I am reading this correctly. "GRVI is an FPGA-efficient RISC-V RV32I soft processor core, hand technology mapped and floorplanned for best performance/area" That means it can't be ported to other families without much effort to achieve similar results. But still, assuming it drops off to half the numbers it's still a very good design. Thanks for the link and also all the work you did on this list. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2020-04-16 14:19 -0700 |
| Message-ID | <737bfbe3-3201-43ba-9388-d4df6dd7a072@googlegroups.com> |
| In reply to | #29464 |
On Thursday, April 16, 2020 at 3:50:10 PM UTC-5, Rick C wrote: > On Thursday, April 16, 2020 at 3:28:22 PM UTC-4, jim.br...@ieee.org wrote: > > On Thursday, April 16, 2020 at 9:40:55 AM UTC-5, Rick C wrote: > > > On Thursday, April 16, 2020 at 6:59:29 AM UTC-4, Theo wrote: > > > > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > > > > In the Forth language group there are occasional discussions of custom > > > > > processors. This is mostly because a simple stack processor can be > > > > > designed to be implemented in an FPGA very easily, taking little resources > > > > > and running at a good speed. Such a stack processor is a good target for > > > > > Forth. > > > > > > > > > > I know there are many other types of CPU designs which are implemented in > > > > > FPGAs. I'm wondering how often these are used by the typical embedded > > > > > developer? > > > > > > > > It's not uncommon when you have an FPGA doing some task to need a processor > > > > in there to manage it - for example to handle error conditions or to report > > > > status over some software-friendly interface like I2C, or classical printf > > > > debugging on a UART. > > > > > > > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > > > > legacy (toolchains aren't that great, etc), although designed to be fairly > > > > small. There's increasing interest in small 32-bit RISC-V cores for this > > > > niche, since the toolchain is improving and the licensing conditions more > > > > liberal (RISC-V itself doesn't design cores, but lots of others - including > > > > ourselves - have made open source cores to the RISC-V specification). > > > > > > Someone showed me that RISC-V can be a small solution, but at that size it isn't fast. So the size performance tradeoff isn't so great. Stack processors tend to be very lean and speed effective without pipelining. I know my processor was designed to run 1 instruction per clock cycle on all instructions. > > > > > > > > > > I don't see that Forth has much to speak to this niche, given these cores > > > > are largely offloading work that's fiddly to do in hardware and people just > > > > want to write some (usually) C to mop up the loose ends. I can't see what > > > > Forth would gain them for this. > > > > > > Not sure what you mean about Forth and "speaking". Forth is a natural language for a stack based processor. Often there is a 1 to 1 mapping of instructions to language words. It is also very easy to retarget to new modifications to a processor design. > > > > > > > > > > If you're talking using these processors as a compute overlay for FPGAs, a > > > > different thing entirely, I'd suggest that a stack processor is likely not > > > > very efficient in terms of throughput. Although I don't have a cite to back > > > > that up. > > > > > > I recall someone had a very large compendium of soft core processors with size and speed measurements with a calculation of something like IPS/LUT. It was amazing what some designs could achieve. I wish I knew where to find that now. > > > > > > -- > > > > > > Rick C. > > > > > > + Get 1,000 miles of free Supercharging > > > + Tesla referral code - https://ts.la/richard11209 > > > > |>very large compendium of soft core processors > > https://opencores.org/projects/up_core_list/summary > > > > Several legacy processors are listed: > > https://opencores.org/projects/up_core_list/downloads > > uP_core_list_by_style-clone190221.pdf > > > > Also look into MISTer as it supports several legacy systems. > > None are competitive speed wise with high performance uP. > > > > With LUTs costing less than $0.001 each some soft core uPs are inexpensive, free if you have unused LUTs and block RAMs. > > For debug, changing block RAM contents is much faster than rerunning the FPGA design. > > I don't think the issue is very often $ with a soft core. At least for me it's about board space and integration with the other FPGA functions. > > Looks like I was mistaken about the speed/size of the RISC-V core. However... it appears to have been hand optimized if I am reading this correctly. > > "GRVI is an FPGA-efficient RISC-V RV32I soft processor core, hand technology mapped and floorplanned for best performance/area" > > That means it can't be ported to other families without much effort to achieve similar results. But still, assuming it drops off to half the numbers it's still a very good design. > > Thanks for the link and also all the work you did on this list. > > -- > > Rick C. > > -- Get 1,000 miles of free Supercharging > -- Tesla referral code - https://ts.la/richard11209 I'm currently showing 36+ distinct RISC-V cores There are probably many more: it's a popular item at many universities. Some of which are optimized for low LUT count. See: https://riscv.org/risc-v-cores/ for a list of FPGA and non-FPGA cores. GRVI was done by Jan Gray. He is expert at keeping LUT count low. It is not open source?
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-16 22:33 +0100 |
| Message-ID | <wrB*qpJPx@news.chiark.greenend.org.uk> |
| In reply to | #29464 |
Rick C <gnuarm.deletethisbit@gmail.com> wrote: > Looks like I was mistaken about the speed/size of the RISC-V core. However... it appears to have been hand optimized if I am reading this correctly. > > "GRVI is an FPGA-efficient RISC-V RV32I soft processor core, hand technology mapped and floorplanned for best performance/area" > > That means it can't be ported to other families without much effort to achieve similar results. But still, assuming it drops off to half the numbers it's still a very good design. This is our Tinsel multithreaded RISC-V core, which is written in a high-level HDL (BSV) and not hand mapped: https://github.com/POETSII/tinsel https://github.com/POETSII/tinsel/blob/master/doc/fpl-2019-paper.pdf To compare: "Another recent overlay is Gray’s GRVI Phalanx [22, 23], a manycore RV32I fabric supporting message-passing via a Hoplite NoC. Gray reports that a single 3-stage GRVI core has an Fmax of 375MHz, uses 320 LUTs, and has a predicted CPI (cycles per instruction) of 1.6. These numbers can be summarised by a single figure of 0.7 MIPS/LUT. By comparison, a single 16-thread pure RV32I Tinsel core (with tightly-coupled data and instruction memories) uses 500 ALMs, clocks at 450MHz, and has a predicted CPI of 1 (there are no pipeline hazards due to multithreading), giving a figure of 0.9 MIPS/LUT. This rough comparison assumes a highlythreaded workload, and involves Fmax and LUT counts taken from different FPGA architectures (Virtex Ultrascale versus Stratix V). Unlike GRVI, Tinsel is not appropriate for singlethreaded workloads. Gray hand-maps a remarkable 1,680 GRVI cores clocking at 250MHz onto a modern, large Xilinx XCVU9P FPGA using relationally placed macros. However, the hand-mapped approach is quite fragile, and its effectiveness could be offset when introducing off-the-shelf IP into the design, e.g. DRAM/SRAM controllers, Ethernet MACs, FPUs, or custom accelerators, all of which are likely to reduce regularity. Off-chip memory access, inter-FPGA communication, and floating-point are left for future work. Gray also cites highlevel programming support as an important goal for the future, which we have begun to explore in this paper." You likely wouldn't want to use it for the kind of management purposes I described earlier, but it's useful for doing compute on larger FPGAs. Theo
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2020-04-17 11:29 +1000 |
| Message-ID | <AD7mG.11198$7r6.5272@fx19.iad> |
| In reply to | #29459 |
On 16/4/20 8:59 pm, Theo wrote: > Rick C <gnuarm.deletethisbit@gmail.com> wrote: >> In the Forth language group there are occasional discussions of custom >> processors. This is mostly because a simple stack processor can be >> designed to be implemented in an FPGA very easily, taking little resources >> and running at a good speed. Such a stack processor is a good target for >> Forth. >> >> I know there are many other types of CPU designs which are implemented in >> FPGAs. I'm wondering how often these are used by the typical embedded >> developer? > > It's not uncommon when you have an FPGA doing some task to need a processor > in there to manage it - for example to handle error conditions or to report > status over some software-friendly interface like I2C, or classical printf > debugging on a UART. > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > legacy (toolchains aren't that great, etc), although designed to be fairly > small. There's increasing interest in small 32-bit RISC-V cores for this > niche, since the toolchain is improving and the licensing conditions more > liberal (RISC-V itself doesn't design cores, but lots of others - including > ourselves - have made open source cores to the RISC-V specification). > > I don't see that Forth has much to speak to this niche, given these cores > are largely offloading work that's fiddly to do in hardware and people just > want to write some (usually) C to mop up the loose ends. I can't see what > Forth would gain them for this. > > If you're talking using these processors as a compute overlay for FPGAs, a > different thing entirely, I'd suggest that a stack processor is likely not > very efficient in terms of throughput. Although I don't have a cite to back > that up. Lattice provide the 8-bit MICO that fits well even on their smallest parts, with a complete C compiler build chain. The actual software is a tyre fire though, running only on some version of Enterprise Linux that hasn't been updated in almost a decade. CH
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-16 18:42 -0700 |
| Message-ID | <55434cd3-4d5e-4d16-b530-a69e0e84d120@googlegroups.com> |
| In reply to | #29471 |
On Thursday, April 16, 2020 at 9:29:07 PM UTC-4, Clifford Heath wrote: > On 16/4/20 8:59 pm, Theo wrote: > > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > >> In the Forth language group there are occasional discussions of custom > >> processors. This is mostly because a simple stack processor can be > >> designed to be implemented in an FPGA very easily, taking little resources > >> and running at a good speed. Such a stack processor is a good target for > >> Forth. > >> > >> I know there are many other types of CPU designs which are implemented in > >> FPGAs. I'm wondering how often these are used by the typical embedded > >> developer? > > > > It's not uncommon when you have an FPGA doing some task to need a processor > > in there to manage it - for example to handle error conditions or to report > > status over some software-friendly interface like I2C, or classical printf > > debugging on a UART. > > > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > > legacy (toolchains aren't that great, etc), although designed to be fairly > > small. There's increasing interest in small 32-bit RISC-V cores for this > > niche, since the toolchain is improving and the licensing conditions more > > liberal (RISC-V itself doesn't design cores, but lots of others - including > > ourselves - have made open source cores to the RISC-V specification). > > > > I don't see that Forth has much to speak to this niche, given these cores > > are largely offloading work that's fiddly to do in hardware and people just > > want to write some (usually) C to mop up the loose ends. I can't see what > > Forth would gain them for this. > > > > If you're talking using these processors as a compute overlay for FPGAs, a > > different thing entirely, I'd suggest that a stack processor is likely not > > very efficient in terms of throughput. Although I don't have a cite to back > > that up. > > Lattice provide the 8-bit MICO that fits well even on their smallest > parts, with a complete C compiler build chain. > > The actual software is a tyre fire though, running only on some version > of Enterprise Linux that hasn't been updated in almost a decade. > > CH A "tyre fire"??? That's one I haven't heard before. I never figured out why the British call the things that make their cars ride smooth by the name of an ancient city. ; ) -- Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2020-04-17 12:35 +1000 |
| Message-ID | <sB8mG.9763$uE.8561@fx24.iad> |
| In reply to | #29473 |
On 17/4/20 11:42 am, Rick C wrote: > On Thursday, April 16, 2020 at 9:29:07 PM UTC-4, Clifford Heath wrote: >> On 16/4/20 8:59 pm, Theo wrote: >>> Rick C <gnuarm.deletethisbit@gmail.com> wrote: >>>> In the Forth language group there are occasional discussions of custom >>>> processors. This is mostly because a simple stack processor can be >>>> designed to be implemented in an FPGA very easily, taking little resources >>>> and running at a good speed. Such a stack processor is a good target for >>>> Forth. >>>> >>>> I know there are many other types of CPU designs which are implemented in >>>> FPGAs. I'm wondering how often these are used by the typical embedded >>>> developer? >>> >>> It's not uncommon when you have an FPGA doing some task to need a processor >>> in there to manage it - for example to handle error conditions or to report >>> status over some software-friendly interface like I2C, or classical printf >>> debugging on a UART. >>> >>> Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit >>> legacy (toolchains aren't that great, etc), although designed to be fairly >>> small. There's increasing interest in small 32-bit RISC-V cores for this >>> niche, since the toolchain is improving and the licensing conditions more >>> liberal (RISC-V itself doesn't design cores, but lots of others - including >>> ourselves - have made open source cores to the RISC-V specification). >>> >>> I don't see that Forth has much to speak to this niche, given these cores >>> are largely offloading work that's fiddly to do in hardware and people just >>> want to write some (usually) C to mop up the loose ends. I can't see what >>> Forth would gain them for this. >>> >>> If you're talking using these processors as a compute overlay for FPGAs, a >>> different thing entirely, I'd suggest that a stack processor is likely not >>> very efficient in terms of throughput. Although I don't have a cite to back >>> that up. >> >> Lattice provide the 8-bit MICO that fits well even on their smallest >> parts, with a complete C compiler build chain. >> >> The actual software is a tyre fire though, running only on some version >> of Enterprise Linux that hasn't been updated in almost a decade. >> >> CH > > A "tyre fire"??? That's one I haven't heard before. > > I never figured out why the British call the things that make their cars ride smooth by the name of an ancient city. Australians too. Some US language is ancient English (but modern English has moved on), and sometimes its the reverse. "Aluminium/Aluminum" is an example where English moved on (to improve standardisation). CH
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web