Altera Cyclone replacement

[Stef]

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.

 

[HT-Lab]

On 25/01/2019 14:58, 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 :-( )


Hi Stef,

Try www.octopart.com, there are several distributors that still have
some types in stock.

Good luck,
Hans
www.ht-lab.com

 

[Adam GĂłrski]

On 2019-01-25 15:58, 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 :-( )

Hi,

Are you looking for somebody who can transfer you project from Altera
Cyclone to Cyclone V ?

If yes, my email is gorskia @ wp.pl.
My small R&D company is looking for new customers.

Best regards

Adam GĂłrski

 

[kkoorndyk]

On Friday, January 25, 2019 at 10:16:04 AM UTC-5, 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.

Wow. The original Cyclone family is really old technology. Do you have the source for the design and the Nios?

We do a lot of obsolescence respins for customers like this, so yes it is possible. Sometimes it requires *some* redesign to target the appropriate primitives in the newer families, etc.

I would not recommend targeting the Cyclone IV as that family is pushing 10 years old now. Cyclone V was released 4-5 years ago and Cyclone 10 is the latest in their "low-cost" portfolio. Given the low logic density of the original design, you might consider the MAX10 instead.

Another factor to consider is whether the current design uses the original 16-bit Nios or the 32-bit Nios II. I mention it because a lot of people simply refer to the Nios II as Nios but when we're talking about porting an older design it matters. That may impact how easy it is to port the design.

 

On Friday, January 25, 2019 at 10:16:04 AM UTC-5, 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 :-( )

Unless device specific features were instantiated, there is little to port. The HDL source should compile without issues. There will be a pinout specification file that assigns pin numbers and I/O characteristics which typically is device specific. This will need to be redone, but since the package is changing that's not surprising though, is it? Just be sure to keep the characteristics while changing the pin numbers.

There are often sources for old FPGAs. I am still using a Lattice part that was EOL some six years ago.

Rick C.

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

 

[Stef]

On 2019-01-25 HT-Lab wrote in comp.arch.fpga:

On 25/01/2019 14:58, 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 :-( )


Hi Stef,

Try www.octopart.com, there are several distributors that still have
some types in stock.

Okay, didn't expect that to be so easy, gues that's one of the reasons
I'm not in purchasing. ;-)
Turns out at least small quantities are available from Arrow, Avnet,
Mouser, etc.

So if we only do one run, this would be sufficient. Thanks.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Executive ability is prominent in your make-up.

 

[Stef]

On 2019-01-26 kkoorndyk wrote in comp.arch.fpga:

On Friday, January 25, 2019 at 10:16:04 AM UTC-5, 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 :-( )

Wow. The original Cyclone family is really old technology.

Indeed! Friday I dug up some datasheets from 2007 and found that a bit old
already. But Today I found the correct Intel page and it turns out the
original Cyclone was launched in 2002! Suddenly remembered I once played
with Cyclone a little. Found the old Cyclone II eval kit in a box.

> Do you have the source for the design and the Nios?

Don't know yet. For now just checking if it's even worth getting it.
(always good to have as reference for a new design ofcourse, but for
that you do not need a working build environment etc.)

> We do a lot of obsolescence respins for customers like this, so yes it is possible. Sometimes it requires *some* redesign to target the appropriate primitives in the newer families, etc.

Okay sounds promising. How about board design, package, pinout and supply
voltages?

> I would not recommend targeting the Cyclone IV as that family is pushing 10 years old now. Cyclone V was released 4-5 years ago and Cyclone 10 is the latest in their "low-cost" portfolio. Given the low logic density of the original design, you might consider the MAX10 instead.

Ah, friday I somehow landed on an Intel page where I only found Cyclone IV
and V? Today I found the compte portfolio. ;-)

The largest Cyclone had 20k LEs, the smallest Cyclone 10 already has 85k
LEs. MAX 10 ranges from 2k to 50k LEs, so should easely fit.

> Another factor to consider is whether the current design uses the original 16-bit Nios or the 32-bit Nios II. I mention it because a lot of people simply refer to the Nios II as Nios but when we're talking about porting an older design it matters. That may impact how easy it is to port the design.

Don't know yet. Just found the word 'Nios' in the docs we have so far. But
thanks for the warning. 16-bit Nios is no longer supported?


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

The best cure for insomnia is to get a lot of sleep.
-- W. C. Fields

 

[Stef]

On 2019-01-27 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:

On Friday, January 25, 2019 at 10:16:04 AM UTC-5, 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 :-( )

Unless device specific features were instantiated, there is little to port. The HDL source should compile without issues. There will be a pinout specification file that assigns pin numbers and I/O characteristics which typically is device specific. This will need to be redone, but since the package is changing that's not surprising though, is it? Just be sure to keep the characteristics while changing the pin numbers.

Okay, not too hard then (probably ;-) ). But if I read correctly, you don't
expect pin compatible devices to exist? So board modifications are inevitable.

There are often sources for old FPGAs. I am still using a Lattice part that was EOL some six years ago.

Yes, found a few already thanks to another reply. But I am a little worried
about the future proofness of that approach.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Don't be humble ... you're not that great.
-- Golda Meir

 

[Stef]

On 2019-01-25 Adam GĂłrski wrote in comp.arch.fpga:

On 2019-01-25 15:58, 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 :-( )



Hi,

Are you looking for somebody who can transfer you project from Altera
Cyclone to Cyclone V ?

Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
recent discoveries. ;-)

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Gotcha, you snot-necked weenies!"
-- Post Bros. Comics

 

[Stef]

On 2019-01-28 Stef wrote in comp.arch.fpga:

The largest Cyclone had 20k LEs, the smallest Cyclone 10 already has 85k
LEs. MAX 10 ranges from 2k to 50k LEs, so should easely fit.

Oops, smallest Cyclone 10 GX is 85k LEs. But then there is Cyclone 10 LP,
which starts at 6k LEs, going up to 120k.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"This generation may be the one that will face Armageddon."
-- Ronald Reagan, "People" magazine, December 26, 1985

 

On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:

On 2019-01-25 Adam GĂłrski wrote in comp.arch.fpga:
On 2019-01-25 15:58, 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 :-( )



Hi,

Are you looking for somebody who can transfer you project from Altera
Cyclone to Cyclone V ?

Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
recent discoveries. ;-)

If you are porting to a new family, why limit yourself to Cyclones? If the HDL was written without using specific device features, you can likely port it as easily to another brand as to a new device. Xilinx and Lattice and even Microsemi make competitive FPGAs. But then I suppose there is a license issue with using NIOS on something other than an Altera part. That's another reason why I don't use proprietary code in my designs.

At one time I worked for a company who used a lot of FPGAs. They didn't have brand loyalty. They would use whichever device was best for a given design. So their policy was to not use anything specific to a brand... well, for the most part. I recall we got a demonstration one day by my boss who had created a design which needed to be updated. Seems he had included one tiny piece that required hand routing in the chip editor to meet the timing spec... and had not documented this anywhere!!! So we received a bit of oral tradition. This company makes test equipment that is sold to all the major comms manufacturers. lol!

Given that Altera is now owned by Intel, I would use this opportunity to replace the NIOS processor with something independent of device manufacturer and remove your brand dependency. There are tons of third party processors out there. I can recommend one if you need.


Rick C.

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

 

[kkoorndyk]

On Monday, January 28, 2019 at 6:28:05 AM UTC-5, gnuarm.del...@gmail.com wrote:

On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:
On 2019-01-25 Adam GĂłrski wrote in comp.arch.fpga:
On 2019-01-25 15:58, 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 :-( )



Hi,

Are you looking for somebody who can transfer you project from Altera
Cyclone to Cyclone V ?

Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
recent discoveries. ;-)

If you are porting to a new family, why limit yourself to Cyclones? If the HDL was written without using specific device features, you can likely port it as easily to another brand as to a new device. Xilinx and Lattice and even Microsemi make competitive FPGAs. But then I suppose there is a license issue with using NIOS on something other than an Altera part. That's another reason why I don't use proprietary code in my designs.

At one time I worked for a company who used a lot of FPGAs. They didn't have brand loyalty. They would use whichever device was best for a given design. So their policy was to not use anything specific to a brand... well, for the most part. I recall we got a demonstration one day by my boss who had created a design which needed to be updated. Seems he had included one tiny piece that required hand routing in the chip editor to meet the timing spec... and had not documented this anywhere!!! So we received a bit of oral tradition. This company makes test equipment that is sold to all the major comms manufacturers. lol!

Given that Altera is now owned by Intel, I would use this opportunity to replace the NIOS processor with something independent of device manufacturer and remove your brand dependency. There are tons of third party processors out there. I can recommend one if you need.


Rick C.

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

This is an excellent point! The company I work for is a design partner for both Brand A/I and Brand X so I'm hesitant speak poorly of either. However, after the acquisition in 2016, it appears that Intel halted *everything* in the Altera business and they're still catching up with the rebranding on all of their documentation, website, etc. Their forums are still a real mess, so even searching for solutions is a challenge.

For anyone in the same position as the OP, if the sales volumes and the forecast are long enough, I'd recommend retargeting another device, preferably Xilinx. If your projected volume is high enough that you aren't going to be able to find drop-in parts on the market, you're going to be looking at a board respin for the new devices (or an interposer, if possible) and some porting effort anyway. 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.

 

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

 

[Stef]

On 2019-01-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:

On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:

Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
recent discoveries. ;-)

If you are porting to a new family, why limit yourself to Cyclones? If the HDL was written without using specific device features, you can likely port it as easily to another brand as to a new device. Xilinx and Lattice and even Microsemi make competitive FPGAs. But then I suppose there is a license issue with using NIOS on something other than an Altera part. That's another reason why I don't use proprietary code in my designs.

I was under the assumption that porting to Cyclones would be less work than
moving to other families/manufacturers. And I think that is still the case
if NIOS is part of the existing design.

If it really comes to porting to another architecture, we might even port
the whole thing to a microcontroller. As far as we can see now, there was
no real need for an FPGA in that design. I/O might be a problem, but that
is one of the thing to investigate if it comes to porting.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Pohl's law:
Nothing is so good that somebody, somewhere, will not hate it.

 

On Wednesday, January 30, 2019 at 3:44:08 AM UTC-5, Stef wrote:

On 2019-01-28 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:

Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
recent discoveries. ;-)

If you are porting to a new family, why limit yourself to Cyclones? If the HDL was written without using specific device features, you can likely port it as easily to another brand as to a new device. Xilinx and Lattice and even Microsemi make competitive FPGAs. But then I suppose there is a license issue with using NIOS on something other than an Altera part. That's another reason why I don't use proprietary code in my designs.

I was under the assumption that porting to Cyclones would be less work than
moving to other families/manufacturers. And I think that is still the case
if NIOS is part of the existing design.

If it really comes to porting to another architecture, we might even port
the whole thing to a microcontroller. As far as we can see now, there was
no real need for an FPGA in that design. I/O might be a problem, but that
is one of the thing to investigate if it comes to porting.

Don't suggest to me that an FPGA design should be ported to an MCU. I'm in the other camp that MCU designs can often be effectively ported to FPGAs. I find the issues with sharing a single CPU to perform multiple tasks in real time to be much greater than the issues of fitting a design into an FPGA. People cite all sorts of "facts" about using FPGAs that don't seem to apply in my designs, so I'm not sure what they are doing wrong. I find FPGAs to be easy to design and work with. I also find much fewer problems on the lab bench and in the field than others do with software based designs.

But certainly the easy route is to continue making the boards with the old parts. Just be careful of your sources and verify each lot of devices you buy before using them in a design. There are a lot of counterfeits these days. EOL devices are popular targets.


Rick C.

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

 

[kkoorndyk]

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."

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.

 

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

 

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

]>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

 

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:
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

]>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

 

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:
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

]>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