Custom CPU Designs

On 2020-04-16, Theo <theom+news@chiark.greenend.org.uk> wrote:

> - if you have the space it's better to use an on-chip BRAM rather
>   than SDRAM, given the SDRAM is often running at ~100MHz x 16 bits,
>   which makes even instruction fetch multi-cycle.  DDR is better but
>   the memory controllers are much more complex, and life gets easier
>   when you have cache.

I don't remember if we ever got it to work reliably at 100M
full-duplex.  I know it was close, and it worked OK half-duplex.  I do
remember there was a _lot_ of messing around with interleave, burst
length, etc.

> - they've upgraded to a plugin for a modern version of Eclipse
>   rather than a fork from 2005, but it's still Eclipse :( I just
>   drive the shell scripts directly (although the pile of Make they
>   generate isn't that nice).  I've never had it need a dongle.

IIRC, we eventually got to the point where we only needed the dongle
when the HW guys changed something and the register map changed.  I
ended up writing several scripts so we could use plain old Makefiles
after the register maps had been generated.

> - the JTAG interface is horrible and I've spent way too much time
>   reverse engineering it[1] and working around its foibles, in
>   particularly the JTAG UART which is broken in several ways (google
>   'JTAG Atlantic' for some workarounds)

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.

>> After spending a year developing prototype products that would never
>> quite work, we abandoned the NIOS2 in favor of an NXP Cortex M3.
>
> These days a RISC-V CPU in FPGA solves a lot of the horrible
> proprietaryness, although you still have to glue the toolchain
> together yourself (git clone riscv-gcc).
>
> But if you can do the job with a hard MCU I can't see why you'd want
> an FPGA.

We needed a pretty decent-sized FPGA for custom peripherals and an I/O
processor.  So, Altera sold somebody on the idea of moving the uC into
the FPGA also.

> Personally I much prefer the ARM cores on FPGAs these days - they're a
> Proper CPU that Just Works.

Definitely. The M-class parts are so cheap, there's not much point in
thinking about doing it in an FPGA.

> [1] Did you know the Altera product codenames were based on dragons from How
> to Train Your Dragon?  Interesting what you find out when running strace(1)
> on the binary...

I did not know that. :)

--
Grant

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.

On Thursday, April 16, 2020 at 7:13:45 PM UTC-5, 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.

If you need only a little programmable logic consider the Cypress PSoC series.  The Microchip SmartFusion2 is relatively low cost.  Both have Cortex M3 or M4 uP.

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

On Thursday, April 16, 2020 at 8:13:45 PM UTC-4, 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.

There's a chip that goes the other direction.  The GA144 has 144 very fast, very tiny CPUs in an FPGA fashion with no FPGA fabric.  

It's not a popular chip because most people are invested in the single CPU, lots of memory paradigm and focusing their efforts on making a single CPU work like it's many CPUs doing many different things.  Using this chip requires a very different mindset because of the memory size limitations which are inherent in the CPU design.  

That said, FPGA makers are rather stuck in the -larger is better- rut mostly because their bread and butter customer base, the comms vendors, want large FPGAs with fast ARM processors if any.  

I recall a rather old Xilinx line, Virtex II Pro had Power PC CPUs I think.  Either two or only one or none in the smallest device.  Pre-ARM days I guess. 

Atmel had a line of not very well received FPGAs.  They had a version which incorporated an 8 bitter, possibly a AVR, but I don't think it was that.  Too long ago to remember.  It had a 4-5 letter acronym for a name.  SLIC or something like that. 

ActelxxxxxMicrosemixxxxxxxxxMicrochip has some FPGAs with an ARM CPU.  A bit pricey for me and they only come in large packages or very fine pitch BGAs. 

-- 

  Rick C.

  -+ Get 1,000 miles of free Supercharging
  -+ Tesla referral code - https://ts.la/richard11209

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

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

On Thursday, April 16, 2020 at 10:35:07 PM UTC-4, Clifford Heath wrote:
> 
> 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).

Sorry, can you explain the aluminium/aluminum thing?  I know some people pronounce it with an accent (not saying who) but I don't get the English moved on thing. 

-- 

  Rick C.

  ++ Get 1,000 miles of free Supercharging
  ++ Tesla referral code - https://ts.la/richard11209

On 17/4/20 1:01 pm, Rick C wrote:
> On Thursday, April 16, 2020 at 10:35:07 PM UTC-4, Clifford Heath wrote:
>>
>> 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).
> 
> Sorry, can you explain the aluminium/aluminum thing?  I know some people pronounce it with an accent (not saying who) but I don't get the English moved on thing.

Aluminum is the original name, which Americans retained when the English 
decided to standardise on the -ium extension that was being used with 
most other metals already.

That's my understanding anyhow.

CH

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> There's a chip that goes the other direction.  The GA144 has 144 very
> fast, very tiny CPUs in an FPGA fashion with no FPGA fabric.

Right, but the idea is to have both.