Altera Cyclone replacement

On Wednesday, January 30, 2019 at 8:56:28 PM UTC-5, jim.bra...@ieee.org wrote:
> On Wednesday, January 30, 2019 at 7:37:56 PM UTC-6, gnuarm.del...@gmail.com wrote:
> > On Wednesday, January 30, 2019 at 7:42:54 PM UTC-5, jim.bra...@ieee.org wrote:
> > > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote:
> > > 
> > > ]>Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.
> > > 
> > > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze
> > > 
> > > No NIOS clones that I know of
> > > 
> > > ]>But perhaps more importantly, they are far from optimal.
> > > Ugh, they have some of the best figure-of-merit numbers available.
> > >   (Instructions per second per LUT)
> > > And are available in many configuration options.
> > > 
> > > There are a large variety of RISC-V cores available some of which have low LUT counts.
> > > 
> > > Jim Brakefield
> > 
> > Not sure what figures you are talking about.  Has anyone compiled a comparison?  
> > 
> > 
> >   Rick C.
> > 
> >   ++ Get 6 months of free supercharging
> >   ++ Tesla referral code - https://ts.la/richard11209
> 
> Altera/Intel: "Nios II Performance Benchmarks
> Xilinx: appendix of MicroBlaze Processor Reference Guide

Not sure what these are about.  They certainly don't compare third party implementations of their architectures. 

  Rick C.

  --- Get 6 months of free supercharging
  --- Tesla referral code - https://ts.la/richard11209

Am 31.01.19 um 01:42 schrieb jim.brakefield@ieee.org:
> On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote:
>> On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote:

> 
> ]>Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.
> 
> Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze

Proprietary maybe; when the re-implementation is clean, it's OK.
You might also have to re-implement the assembler & C-compiler
for license reasons.

I once have changed the register implementation of a PICO-blaze.
That was not too hard. Its VHDL representation is compiled
with the rest of your FPGA circuit.

The problem was, we used picoblazes in an ORIGINAL dinosaur Virtex
in a space application, and we had to scrubb the configuration
memory every minute or so. That means reloading the configuration
memory to fight accumulation of bad bits due to radiation etc.
It works just like booting the FPGA at powerup - and killing this
process one clock before the before the global reset happens!

The icing on the cake was that the reload circuitry was in the FPGA
itself. That's much like exchanging the carpet under your feet.

I have witten a nice package of triple module redundant standard logic
vectors for that, and for other sensitive processing.

tmr_sl and tmr_slv could be used almost like standard_logic and the
peculiarities were carefully hidden, like avoiding that the ISE
proudly optimizes the redundancy away. The Xilinx TMR tool was
unavailable for European space projects because of ITER. :-(

(Maybe I should do an open source re-implementation in modern VHDL
as a WARM THANK YOU. I know now how to make it even better and we
could make tamagotchis for the children of Fukushima.)

But I disgress. The reason for the picoblaze modification was
that picoblaze uses CLB rams for its registers and these are
really snippets of the configuration RAM. So, during each
scrubbing of the configuration the CPU forgets its register contents.

Replacing the rams with arrays of flip-flops increased the
resource consumption but it was _not_ much slower.

best regards,
Gerhard


Hoffmann Consulting:  ANALOG, RF and DSP Design.

On Friday, January 25, 2019 at 5:16:04 PM UTC+2, Stef wrote:
> Hi,
> 
> We got an old design with an Altera Cyclone FPGA (EP1C12F324).
> These are probably obsolete (Can't find any info on them on the Intel
> site, Farnell is out of stock, etc.). Currently active are the Cyclone-IV
> and Cyclone-V if I understood correctly.
> 
> Is a design from a Cyclone portable to a Cyclone-IV/V? What kind of
> changes should I expect to code and board? Design includes NIOS.
> 
> Or alternatively, are their sources for these old Cyclone chips?
> (We actually would need 3 different types :-( )
> 
> 
> -- 
> Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
> 
> There is never time to do it right, but always time to do it over.

As you probably found out yourself, the least painful and the most cost effective migration path is to Cyclone 10LP. Despite the name 10, it is relatively old family (60 nm) that is less likely than new chips to have problems with 3/3.3V external I/O.
MAX 10 is very cheap at 2KLUTs. If your design is bigger than that then Cy10LP would be cheaper.

For relatively big volumes consider Lattice Mach. Their list price is no good, but volume discounts are fantastic. But be ready for much higher level of pain during development than what you probably accustomed to with Cyclone.

On Thursday, January 31, 2019 at 2:42:54 AM UTC+2, jim.bra...@ieee.org wrote:
> On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote:
> > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote:
> > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote:
> > > > You may as well take the opportunity to "future proof" the design by migrating to another vendor that isn't likely to get acquired or axed.  Xilinx has the single core Zynq-7000 devices if you want to go with a more main-stream, ARM processor sub-system (although likely overkill for whatever your Nios is doing).  Otherwise, the Artix-7 and Spartan-7 would be good targets if you want to migrate to a Microblaze or some other soft core.  The Spartan-7 family is essentially the Artix-7 fabric with the transcievers removed and are offered in 6K to 100K logic cell densities.
> > > > 
> > > > I don't think you actually got my point.  Moving to a Spartan by using a MicroBlaze processor isn't "future proofing" anything.  It is just shifting from one brand to another with the exact same problems.  
> > > > 
> > > > If you want to future proof a soft CPU design you need to drop any FPGA company in-house processor and use an open source processor design.  Then you can use any FPGA you wish.  
> > > > 
> > > > Here is some info on the J1, an open source processor that was used to replace a microblaze when it became unequal to the task at hand.  
> > > > 
> > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
> > > > 
> > > > http://www.excamera.com/sphinx/fpga-j1.html
> > > > 
> > > > http://www.excamera.com/files/j1.pdf
> > > > 
> > > > 
> > > >   Rick C.
> > > > 
> > > >   -- Get 6 months of free supercharging
> > > >   -- Tesla referral code - https://ts.la/richard11209
> > > 
> > > No, I got your point perfectly, hence the following part of my recommendation:  "or some other soft core."
> > 
> > I am making the point that porting from one proprietary processor to another is of limited value.  Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.  But perhaps more importantly, they are far from optimal.  That's why I posted the info on the J1 processor.  It was invented to replace a Microblaze that wasn't up to the task.  
> > 
> > 
> > > If the original Nios was employed, I'm not entirely convinced a soft core is necessary (yet).  How simple is the software running on it?  Can it reasonably be ported to HDL, thus ensuring portability?  I tend to lean that way unless the SW was simple due to capability limitations in the earlier technologies (e.g., old Cyclone and Nios) and the desire is to add more features that are realizable with new generation devices and soft (or hard) core capabilities.
> > 
> > Sometimes soft CPUs are added to reduce the size of logic.  Other times they are added because of the complexity of expression.  Regardless of how simply we can write HDL, the large part of the engineering world perceives HDL as much more complex than other languages and are not willing to port code to an HDL unless absolutely required.  So if the code is currently in C, it won't get ported to HDL without a compelling reason. 
> > 
> > Personally I think Xilinx and Altera are responsible for the present perception that FPGAs are difficult to use, expensive, large and power hungry.  That is largely true if you use their products only.  Lattice has been addressing a newer market with small, low power, inexpensive devices intended for the mobile market.  Now if someone would approach the issue of ease of use by something more than throwing an IDE on top of their command line tools, the FPGA market can explode into territory presently dominated by MCUs.  
> > 
> > Does anyone really think toasters can only be controlled by MCUs?  We just need a cheap enough FPGA in a suitable package.  
> > 
> > 
> >   Rick C.
> > 
> >   +- Get 6 months of free supercharging
> >   +- Tesla referral code - https://ts.la/richard11209
> 
> ]>Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.
> 
> Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze
> 
> No NIOS clones that I know of
> 

I am playing with one right now. 
Already have half-dozen working variants each with its own advantage/disadvantange in terms of resources usage (LEs vs M9K) and Fmax. The smallest one is still not as small as Altera's Nios2e and the fastest one is still not as fast as Altera's Nios2f. Beating Nios2e on size is in my [near] future plans, beating Altera's Nios2f on speed and features is of lesser priority.

My cores are less full-featured than even nios2e. They are intended for one certain niche that I would call "soft MCU". In particular, the only supported  program memory is what Altera calls "tightly coupled memory", i.e. embedded dual-ported SRAM blocks with no other master connected. Another limitations are absence of exceptions and external interrupts. For me it's o.k. that's how I use nios2e anyway.

I didn't check if what I am doing is legal.
Probably does not matter as long as it's just a repo on github.


> ]>But perhaps more importantly, they are far from optimal.
> Ugh, they have some of the best figure-of-merit numbers available.
>   (Instructions per second per LUT)
> And are available in many configuration options.
> 
> There are a large variety of RISC-V cores available some of which have low LUT counts.

Fixed-instruction-width 32-bit subset of RISC-V ISA is nearly identical to Nios2 down to the level of instruction formats. The biggest difference is 12-bit immediate in RV vs 16-bit in N2. Not a big deal.
So I expect that RV32 cores available in source form can be modified to run Nios2 in few days (or, if original designer is involved, in few hours).

The bigger difference would be external interface. In N2 one expects Avalon-mm. I have no idea what's a standard bus/fabric in the world of RV soft cores and how similar it is to AVM.


> 
> Jim Brakefield

On Wednesday, February 6, 2019 at 6:54:27 AM UTC-5, already...@yahoo.com wrote:
> On Thursday, January 31, 2019 at 2:42:54 AM UTC+2, jim.bra...@ieee.org wrote:
> > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote:
> > > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote:
> > > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote:
> > > > > You may as well take the opportunity to "future proof" the design by migrating to another vendor that isn't likely to get acquired or axed.  Xilinx has the single core Zynq-7000 devices if you want to go with a more main-stream, ARM processor sub-system (although likely overkill for whatever your Nios is doing).  Otherwise, the Artix-7 and Spartan-7 would be good targets if you want to migrate to a Microblaze or some other soft core.  The Spartan-7 family is essentially the Artix-7 fabric with the transcievers removed and are offered in 6K to 100K logic cell densities.
> > > > > 
> > > > > I don't think you actually got my point.  Moving to a Spartan by using a MicroBlaze processor isn't "future proofing" anything.  It is just shifting from one brand to another with the exact same problems.  
> > > > > 
> > > > > If you want to future proof a soft CPU design you need to drop any FPGA company in-house processor and use an open source processor design.  Then you can use any FPGA you wish.  
> > > > > 
> > > > > Here is some info on the J1, an open source processor that was used to replace a microblaze when it became unequal to the task at hand.  
> > > > > 
> > > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
> > > > > 
> > > > > http://www.excamera.com/sphinx/fpga-j1.html
> > > > > 
> > > > > http://www.excamera.com/files/j1.pdf
> > > > > 
> > > > > 
> > > > >   Rick C.
> > > > > 
> > > > >   -- Get 6 months of free supercharging
> > > > >   -- Tesla referral code - https://ts.la/richard11209
> > > > 
> > > > No, I got your point perfectly, hence the following part of my recommendation:  "or some other soft core."
> > > 
> > > I am making the point that porting from one proprietary processor to another is of limited value.  Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.  But perhaps more importantly, they are far from optimal.  That's why I posted the info on the J1 processor.  It was invented to replace a Microblaze that wasn't up to the task.  
> > > 
> > > 
> > > > If the original Nios was employed, I'm not entirely convinced a soft core is necessary (yet).  How simple is the software running on it?  Can it reasonably be ported to HDL, thus ensuring portability?  I tend to lean that way unless the SW was simple due to capability limitations in the earlier technologies (e.g., old Cyclone and Nios) and the desire is to add more features that are realizable with new generation devices and soft (or hard) core capabilities.
> > > 
> > > Sometimes soft CPUs are added to reduce the size of logic.  Other times they are added because of the complexity of expression.  Regardless of how simply we can write HDL, the large part of the engineering world perceives HDL as much more complex than other languages and are not willing to port code to an HDL unless absolutely required.  So if the code is currently in C, it won't get ported to HDL without a compelling reason. 
> > > 
> > > Personally I think Xilinx and Altera are responsible for the present perception that FPGAs are difficult to use, expensive, large and power hungry.  That is largely true if you use their products only.  Lattice has been addressing a newer market with small, low power, inexpensive devices intended for the mobile market.  Now if someone would approach the issue of ease of use by something more than throwing an IDE on top of their command line tools, the FPGA market can explode into territory presently dominated by MCUs.  
> > > 
> > > Does anyone really think toasters can only be controlled by MCUs?  We just need a cheap enough FPGA in a suitable package.  
> > > 
> > > 
> > >   Rick C.
> > > 
> > >   +- Get 6 months of free supercharging
> > >   +- Tesla referral code - https://ts.la/richard11209
> > 
> > ]>Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.
> > 
> > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze
> > 
> > No NIOS clones that I know of
> > 
> 
> I am playing with one right now. 
> Already have half-dozen working variants each with its own advantage/disadvantange in terms of resources usage (LEs vs M9K) and Fmax. The smallest one is still not as small as Altera's Nios2e and the fastest one is still not as fast as Altera's Nios2f. Beating Nios2e on size is in my [near] future plans, beating Altera's Nios2f on speed and features is of lesser priority.
> 
> My cores are less full-featured than even nios2e. They are intended for one certain niche that I would call "soft MCU". In particular, the only supported  program memory is what Altera calls "tightly coupled memory", i.e. embedded dual-ported SRAM blocks with no other master connected. Another limitations are absence of exceptions and external interrupts. For me it's o.k. that's how I use nios2e anyway.
> 
> I didn't check if what I am doing is legal.
> Probably does not matter as long as it's just a repo on github.
> 
> 
> > ]>But perhaps more importantly, they are far from optimal.
> > Ugh, they have some of the best figure-of-merit numbers available.
> >   (Instructions per second per LUT)
> > And are available in many configuration options.
> > 
> > There are a large variety of RISC-V cores available some of which have low LUT counts.
> 
> Fixed-instruction-width 32-bit subset of RISC-V ISA is nearly identical to Nios2 down to the level of instruction formats. The biggest difference is 12-bit immediate in RV vs 16-bit in N2. Not a big deal.
> So I expect that RV32 cores available in source form can be modified to run Nios2 in few days (or, if original designer is involved, in few hours).
> 
> The bigger difference would be external interface. In N2 one expects Avalon-mm. I have no idea what's a standard bus/fabric in the world of RV soft cores and how similar it is to AVM.

Should I assume you are not using C to program these CPUs? 

If that is correct, have you considered a stack based CPU?  When you refer to CPUs like the RISC-V I'm thinking they use thousands of LUT4s.  Many stack based CPUs can be implemented in 1k LUT4s or less.  They can run fast, >100 MHz and typically are not pipelined.  

There is a lot of interest in stack CPUs in the Forth community since typically their assembly language is similar to the Forth virtual machine.  

I'm not familiar with Avalon and I don't know what N2 is.  A popular bus in the FPGA embedded world is Wishbone.  



  Rick C.

  --+ Tesla referral code - https://ts.la/richard11209

On Thursday, February 7, 2019 at 8:36:36 PM UTC+2, gnuarm.del...@gmail.com wrote:
> On Wednesday, February 6, 2019 at 6:54:27 AM UTC-5, already...@yahoo.com wrote:
> > On Thursday, January 31, 2019 at 2:42:54 AM UTC+2, jim.bra...@ieee.org wrote:
> > > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote:
> > > > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote:
> > > > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote:
> > > > > > You may as well take the opportunity to "future proof" the design by migrating to another vendor that isn't likely to get acquired or axed.  Xilinx has the single core Zynq-7000 devices if you want to go with a more main-stream, ARM processor sub-system (although likely overkill for whatever your Nios is doing).  Otherwise, the Artix-7 and Spartan-7 would be good targets if you want to migrate to a Microblaze or some other soft core.  The Spartan-7 family is essentially the Artix-7 fabric with the transcievers removed and are offered in 6K to 100K logic cell densities.
> > > > > > 
> > > > > > I don't think you actually got my point.  Moving to a Spartan by using a MicroBlaze processor isn't "future proofing" anything.  It is just shifting from one brand to another with the exact same problems.  
> > > > > > 
> > > > > > If you want to future proof a soft CPU design you need to drop any FPGA company in-house processor and use an open source processor design.  Then you can use any FPGA you wish.  
> > > > > > 
> > > > > > Here is some info on the J1, an open source processor that was used to replace a microblaze when it became unequal to the task at hand.  
> > > > > > 
> > > > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
> > > > > > 
> > > > > > http://www.excamera.com/sphinx/fpga-j1.html
> > > > > > 
> > > > > > http://www.excamera.com/files/j1.pdf
> > > > > > 
> > > > > > 
> > > > > >   Rick C.
> > > > > > 
> > > > > >   -- Get 6 months of free supercharging
> > > > > >   -- Tesla referral code - https://ts.la/richard11209
> > > > > 
> > > > > No, I got your point perfectly, hence the following part of my recommendation:  "or some other soft core."
> > > > 
> > > > I am making the point that porting from one proprietary processor to another is of limited value.  Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.  But perhaps more importantly, they are far from optimal.  That's why I posted the info on the J1 processor.  It was invented to replace a Microblaze that wasn't up to the task.  
> > > > 
> > > > 
> > > > > If the original Nios was employed, I'm not entirely convinced a soft core is necessary (yet).  How simple is the software running on it?  Can it reasonably be ported to HDL, thus ensuring portability?  I tend to lean that way unless the SW was simple due to capability limitations in the earlier technologies (e.g., old Cyclone and Nios) and the desire is to add more features that are realizable with new generation devices and soft (or hard) core capabilities.
> > > > 
> > > > Sometimes soft CPUs are added to reduce the size of logic.  Other times they are added because of the complexity of expression.  Regardless of how simply we can write HDL, the large part of the engineering world perceives HDL as much more complex than other languages and are not willing to port code to an HDL unless absolutely required.  So if the code is currently in C, it won't get ported to HDL without a compelling reason. 
> > > > 
> > > > Personally I think Xilinx and Altera are responsible for the present perception that FPGAs are difficult to use, expensive, large and power hungry.  That is largely true if you use their products only.  Lattice has been addressing a newer market with small, low power, inexpensive devices intended for the mobile market.  Now if someone would approach the issue of ease of use by something more than throwing an IDE on top of their command line tools, the FPGA market can explode into territory presently dominated by MCUs.  
> > > > 
> > > > Does anyone really think toasters can only be controlled by MCUs?  We just need a cheap enough FPGA in a suitable package.  
> > > > 
> > > > 
> > > >   Rick C.
> > > > 
> > > >   +- Get 6 months of free supercharging
> > > >   +- Tesla referral code - https://ts.la/richard11209
> > > 
> > > ]>Microblaze is proprietary.  I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well.
> > > 
> > > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze
> > > 
> > > No NIOS clones that I know of
> > > 
> > 
> > I am playing with one right now. 
> > Already have half-dozen working variants each with its own advantage/disadvantange in terms of resources usage (LEs vs M9K) and Fmax. The smallest one is still not as small as Altera's Nios2e and the fastest one is still not as fast as Altera's Nios2f. Beating Nios2e on size is in my [near] future plans, beating Altera's Nios2f on speed and features is of lesser priority.
> > 
> > My cores are less full-featured than even nios2e. They are intended for one certain niche that I would call "soft MCU". In particular, the only supported  program memory is what Altera calls "tightly coupled memory", i.e. embedded dual-ported SRAM blocks with no other master connected. Another limitations are absence of exceptions and external interrupts. For me it's o.k. that's how I use nios2e anyway.
> > 
> > I didn't check if what I am doing is legal.
> > Probably does not matter as long as it's just a repo on github.
> > 
> > 
> > > ]>But perhaps more importantly, they are far from optimal.
> > > Ugh, they have some of the best figure-of-merit numbers available.
> > >   (Instructions per second per LUT)
> > > And are available in many configuration options.
> > > 
> > > There are a large variety of RISC-V cores available some of which have low LUT counts.
> > 
> > Fixed-instruction-width 32-bit subset of RISC-V ISA is nearly identical to Nios2 down to the level of instruction formats. The biggest difference is 12-bit immediate in RV vs 16-bit in N2. Not a big deal.
> > So I expect that RV32 cores available in source form can be modified to run Nios2 in few days (or, if original designer is involved, in few hours).
> > 
> > The bigger difference would be external interface. In N2 one expects Avalon-mm. I have no idea what's a standard bus/fabric in the world of RV soft cores and how similar it is to AVM.
> 
> Should I assume you are not using C to program these CPUs? 
> 

That would be a wrong assumption.
An exact opposite is far closer to reality - I pretty much never use anything, but C to program these CPUs.

> If that is correct, have you considered a stack based CPU?  When you refer to CPUs like the RISC-V I'm thinking they use thousands of LUT4s.

It depends on performance, one is looking for. 
2-2.5 KLUT4s (+few embedded memory blocks and multipliers) is a size of fully pipelined single-issue CPU with direct-mapped instruction and data caches, multiplier and divider that runs at very decent Fmax, but features no MMUs or MPU.
On the other end of the spectrum you find winners of RISC-V core size competition - under 400 LUTs, but (I would guess, didn't check it), glacially slow in terms of CPI. But Fmax is still decent.

Half-dozen Nios2 cores of mine is in the middle - 700 to 850 LUT4s, CPI ranging from (approximately) 2.1 to 4.7 and Fmax ranging from reasonable to impractically high. 
But my main goal was (is) a learning experience rather than practicality. In particular, for majority of variants I set to myself impractical constrain of implementing register file in a single embedded memory block. Doing it in two blocks is far more practical, but less challenging. The same goes with aiming to very high Fmax- not practical, but fun.
May be, after I explore another half-dozen of dozen of fun possibilities I will settle on building the most practical solutions. But not less probable that I'll lose interest and/or focus before that. I am not too passionate about the whole thing.


>  Many stack based CPUs can be implemented in 1k LUT4s or less.  They can run fast, >100 MHz and typically are not pipelined.  
> 
> There is a lot of interest in stack CPUs in the Forth community since typically their assembly language is similar to the Forth virtual machine.  
> 
> I'm not familiar with Avalon and I don't know what N2 is. 

N2 is my shortcut for Nios2.

> A popular bus in the FPGA embedded world is Wishbone.  
> 

I payed attention that Wishbone is popular in Lattice cycles. But Altera world is many times bigger than Lattice and here Avalon is a king. Also,  when performance matters, Aavalon is much better technically.


> 
> 
>   Rick C.
> 
>   --+ Tesla referral code - https://ts.la/richard11209

On Thursday, February 7, 2019 at 4:00:57 PM UTC-5, already...@yahoo.com wro=
te:
> On Thursday, February 7, 2019 at 8:36:36 PM UTC+2, gnuarm.del...@gmail.co=
m wrote:
> >=20
> > Should I assume you are not using C to program these CPUs?=20
> >=20
>=20
> That would be a wrong assumption.
> An exact opposite is far closer to reality - I pretty much never use anyt=
hing, but C to program these CPUs.
>=20
> > If that is correct, have you considered a stack based CPU?  When you re=
fer to CPUs like the RISC-V I'm thinking they use thousands of LUT4s.
>=20
> It depends on performance, one is looking for.=20
> 2-2.5 KLUT4s (+few embedded memory blocks and multipliers) is a size of f=
ully pipelined single-issue CPU with direct-mapped instruction and data cac=
hes, multiplier and divider that runs at very decent Fmax, but features no =
MMUs or MPU.
> On the other end of the spectrum you find winners of RISC-V core size com=
petition - under 400 LUTs, but (I would guess, didn't check it), glacially =
slow in terms of CPI. But Fmax is still decent.
>=20
> Half-dozen Nios2 cores of mine is in the middle - 700 to 850 LUT4s, CPI r=
anging from (approximately) 2.1 to 4.7 and Fmax ranging from reasonable to =
impractically high.=20
> But my main goal was (is) a learning experience rather than practicality.=
 In particular, for majority of variants I set to myself impractical constr=
ain of implementing register file in a single embedded memory block. Doing =
it in two blocks is far more practical, but less challenging. The same goes=
 with aiming to very high Fmax- not practical, but fun.
> May be, after I explore another half-dozen of dozen of fun possibilities =
I will settle on building the most practical solutions. But not less probab=
le that I'll lose interest and/or focus before that. I am not too passionat=
e about the whole thing.

Ok, if you are doing C in FPGA CPUs then you are in a different world than =
the stuff I've worked on.  My projects use a CPU as a controller and often =
have very critical real time requirements.  While C doesn't prevent that, I=
 prefer to just code in assembly language and more importantly, use a CPU d=
esign that provides single cycle execution of all instructions.  That's why=
 I like stack processors, they are easy to design, use a very simple instru=
ction set and the assembly language can be very close to the Forth high lev=
el language.=20


> >  Many stack based CPUs can be implemented in 1k LUT4s or less.  They ca=
n run fast, >100 MHz and typically are not pipelined. =20
> >=20
> > There is a lot of interest in stack CPUs in the Forth community since t=
ypically their assembly language is similar to the Forth virtual machine. =
=20
> >=20
> > I'm not familiar with Avalon and I don't know what N2 is.=20
>=20
> N2 is my shortcut for Nios2.
>=20
> > A popular bus in the FPGA embedded world is Wishbone. =20
> >=20
>=20
> I payed attention that Wishbone is popular in Lattice cycles. But Altera =
world is many times bigger than Lattice and here Avalon is a king. Also,  w=
hen performance matters, Aavalon is much better technically.

I'm not familiar with what bus is preferred where.  I just know that every =
project I've looked at on OpenCores using a standard bus used Wishbone.  If=
 you say Avalon is better, ok.  Is it open source?  Can it be used on other=
 than Intel products?=20


  Rick C.

  -+- Tesla referral code - https://ts.la/richard11209

On Thursday, February 7, 2019 at 11:43:39 PM UTC+2, gnuarm.del...@gmail.com wrote:
> On Thursday, February 7, 2019 at 4:00:57 PM UTC-5, already...@yahoo.com wrote:
> > On Thursday, February 7, 2019 at 8:36:36 PM UTC+2, gnuarm.del...@gmail.com wrote:

> > 
> > > A popular bus in the FPGA embedded world is Wishbone.  
> > > 
> > 
> > I payed attention that Wishbone is popular in Lattice cycles. But Altera world is many times bigger than Lattice and here Avalon is a king. Also,  when performance matters, Aavalon is much better technically.
> 
> I'm not familiar with what bus is preferred where.  I just know that every project I've looked at on OpenCores using a standard bus used Wishbone.  If you say Avalon is better, ok.  Is it open source?  Can it be used on other than Intel products? 
> 

i am not sure what 'open source" means in this context.
Avalon-MM and Avalon-ST are specifications. the documents. The documents freely downloadable from Altera/Intel web site.

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf

A GUI tool, that connects together components, conforming to Avalon specs, which was called SOPC is 00s, then QSYS and now Intel system designer, or something like that, is proprietary close source program.
The code that a tool generates is a normal VHDL or, more often, normal Verilog, that contains copyright statement like that:
// -----------------------------------------------------------
// Legal Notice: (C)2007 Altera Corporation. All rights reserved.  Your
// use of Altera Corporation's design tools, logic functions and other
// software and tools, and its AMPP partner logic functions, and any
// output files any of the foregoing (including device programming or
// simulation files), and any associated documentation or information are
// expressly subject to the terms and conditions of the Altera Program
// License Subscription Agreement or other applicable license agreement,
// including, without limitation, that your use is for the sole purpose
// of programming logic devices manufactured by Altera and sold by Altera
// or its authorized distributors.  Please refer to the applicable
// agreement for further details.

So, you can't legally use QSYS-generated code with non-Intel devices.
But (IANAL) nobody prevents you from writing your own interconnect generation tool. Or from not using any CAD tool at all and just connecting components manually within your HDL. Isn't it mostly what you do with Wishbone components, anyway?

> 
>   Rick C.
> 
>   -+- Tesla referral code - https://ts.la/richard11209

On Thursday, February 7, 2019 at 5:11:20 PM UTC-5, already...@yahoo.com wrote:
> On Thursday, February 7, 2019 at 11:43:39 PM UTC+2, gnuarm.del...@gmail.com wrote:
> > On Thursday, February 7, 2019 at 4:00:57 PM UTC-5, already...@yahoo.com wrote:
> > > On Thursday, February 7, 2019 at 8:36:36 PM UTC+2, gnuarm.del...@gmail.com wrote:
> 
> > > 
> > > > A popular bus in the FPGA embedded world is Wishbone.  
> > > > 
> > > 
> > > I payed attention that Wishbone is popular in Lattice cycles. But Altera world is many times bigger than Lattice and here Avalon is a king. Also,  when performance matters, Aavalon is much better technically.
> > 
> > I'm not familiar with what bus is preferred where.  I just know that every project I've looked at on OpenCores using a standard bus used Wishbone.  If you say Avalon is better, ok.  Is it open source?  Can it be used on other than Intel products? 
> > 
> 
> i am not sure what 'open source" means in this context.
> Avalon-MM and Avalon-ST are specifications. the documents. The documents freely downloadable from Altera/Intel web site.
> 
> https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf
> 
> A GUI tool, that connects together components, conforming to Avalon specs, which was called SOPC is 00s, then QSYS and now Intel system designer, or something like that, is proprietary close source program.
> The code that a tool generates is a normal VHDL or, more often, normal Verilog, that contains copyright statement like that:
> // -----------------------------------------------------------
> // Legal Notice: (C)2007 Altera Corporation. All rights reserved.  Your
> // use of Altera Corporation's design tools, logic functions and other
> // software and tools, and its AMPP partner logic functions, and any
> // output files any of the foregoing (including device programming or
> // simulation files), and any associated documentation or information are
> // expressly subject to the terms and conditions of the Altera Program
> // License Subscription Agreement or other applicable license agreement,
> // including, without limitation, that your use is for the sole purpose
> // of programming logic devices manufactured by Altera and sold by Altera
> // or its authorized distributors.  Please refer to the applicable
> // agreement for further details.
> 
> So, you can't legally use QSYS-generated code with non-Intel devices.
> But (IANAL) nobody prevents you from writing your own interconnect generation tool. Or from not using any CAD tool at all and just connecting components manually within your HDL. Isn't it mostly what you do with Wishbone components, anyway?

Sorry, I don't know what you are referring to.  But my concern with the bus is that it is entirely possible and not at all uncommon for such a design to have aspects which are under license.  Some time ago it was ruled that the Z80 did not infringe on Intel's 8080 design, but the nemonics were copyrighted so Zilog had to develop their own assembler syntax.  ARM decided to protect their CPU design with a patent on some aspect of interrupt handling if I recall correctly.  So while there are equivalent CPUs on the market (RISC-V for example), there are no ARM clones even though all the ARM architecture documents are freely available. 

The point is I don't know if this Altera bus is protected in some way or not.  That's why I was asking.  IANAL either

I think the term open source is pretty clear in all contexts.  Lattice has their own CPU designs for use in FPGAs.  The difference is they don't care if you use then in a Xilinx chip.  


  Rick C.

  -++ Tesla referral code - https://ts.la/richard11209

On 07/02/2019 22:43, gnuarm.deletethisbit@gmail.com wrote:
> On Thursday, February 7, 2019 at 4:00:57 PM UTC-5,
> already...@yahoo.com wrote:
>> On Thursday, February 7, 2019 at 8:36:36 PM UTC+2,
>> gnuarm.del...@gmail.com wrote:

>>> I'm not familiar with Avalon and I don't know what N2 is.
>> 
>> N2 is my shortcut for Nios2.
>> 
>>> A popular bus in the FPGA embedded world is Wishbone.
>>> 
>> 
>> I payed attention that Wishbone is popular in Lattice cycles. But
>> Altera world is many times bigger than Lattice and here Avalon is a
>> king. Also,  when performance matters, Aavalon is much better
>> technically.
> 
> I'm not familiar with what bus is preferred where.  I just know that
> every project I've looked at on OpenCores using a standard bus used
> Wishbone.  If you say Avalon is better, ok.  Is it open source?  Can
> it be used on other than Intel products?
> 

I have no idea of the legal aspects of Avalon (I only ever used it on
Altera devices, long ago).  But technically it is very similar to
Wishbone for many common uses.  Things always get complicated when you
need priorities, bursts, variable wait states, etc., but for simpler and
static connections, I don't remember it as being difficult to mix them.
 (It was many years ago when I did this, however.)

<https://en.wikipedia.org/wiki/Wishbone_(computer_bus)#Comparisons>