Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 161050

Article: 161050
Subject: Re: Altera Cyclone replacement
From: =?UTF-8?Q?Adam_G=c3=b3rski?= <gorskiamalpawpkropkapeel_@xx>
Date: Fri, 25 Jan 2019 18:00:10 +0100
Links: << >>  << T >>  << A >>
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

Article: 161051
Subject: Re: Altera Cyclone replacement
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Sat, 26 Jan 2019 10:55:57 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, January 25, 2019 at 10:16:04 AM UTC-5, Stef wrote:
> Hi,
>=20
> 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.
>=20
> 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.
>=20
> Or alternatively, are their sources for these old Cyclone chips?
> (We actually would need 3 different types :-( )
>=20
>=20
> --=20
> Stef    (remove caps, dashes and .invalid from e-mail address to reply by=
 mail)
>=20
> 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 th=
e source for the design and the Nios?

We do a lot of obsolescence respins for customers like this, so yes it is p=
ossible.  Sometimes it requires *some* redesign to target the appropriate p=
rimitives 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. =20

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 si=
mply refer to the Nios II as Nios but when we're talking about porting an o=
lder design it matters.  That may impact how easy it is to port the design.


Article: 161052
Subject: Re: Altera Cyclone replacement
From: gnuarm.deletethisbit@gmail.com
Date: Sun, 27 Jan 2019 06:16:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, January 25, 2019 at 10:16:04 AM UTC-5, Stef wrote:
> Hi,
>=20
> 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.
>=20
> 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.
>=20
> 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 spe=
cification file that assigns pin numbers and I/O characteristics which typi=
cally is device specific.  This will need to be redone, but since the packa=
ge is changing that's not surprising though, is it?  Just be sure to keep t=
he characteristics while changing the pin numbers. =20

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

  Rick C.

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

Article: 161053
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Mon, 28 Jan 2019 08:53:14 +0100
Links: << >>  << T >>  << A >>
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.

Article: 161054
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Mon, 28 Jan 2019 09:32:12 +0100
Links: << >>  << T >>  << A >>
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

Article: 161055
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Mon, 28 Jan 2019 09:41:17 +0100
Links: << >>  << T >>  << A >>
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

Article: 161056
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Mon, 28 Jan 2019 09:43:45 +0100
Links: << >>  << T >>  << A >>
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

Article: 161057
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Mon, 28 Jan 2019 09:53:33 +0100
Links: << >>  << T >>  << A >>
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

Article: 161058
Subject: Re: Altera Cyclone replacement
From: gnuarm.deletethisbit@gmail.com
Date: Mon, 28 Jan 2019 03:28:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:
> On 2019-01-25 Adam G=C3=B3rski wrote in comp.arch.fpga:
> > On 2019-01-25 15:58, Stef wrote:
> >> Hi,
> >>=20
> >> 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.
> >>=20
> >> 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.
> >>=20
> >> Or alternatively, are their sources for these old Cyclone chips?
> >> (We actually would need 3 different types :-( )
> >>=20
> >>=20
> >
> > Hi,
> >
> > Are you looking for somebody who can transfer you project from Altera=
=20
> > Cyclone to Cyclone V ?
>=20
> 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 por=
t 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 lice=
nse issue with using NIOS on something other than an Altera part.  That's a=
nother reason why I don't use proprietary code in my designs. =20

At one time I worked for a company who used a lot of FPGAs.  They didn't ha=
ve brand loyalty.  They would use whichever device was best for a given des=
ign.  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 timin=
g 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! =20

Given that Altera is now owned by Intel, I would use this opportunity to re=
place 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.=20


  Rick C.

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

Article: 161059
Subject: Re: Altera Cyclone replacement
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Mon, 28 Jan 2019 07:49:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 28, 2019 at 6:28:05 AM UTC-5, gnuarm.del...@gmail.com wr=
ote:
> On Monday, January 28, 2019 at 3:55:24 AM UTC-5, Stef wrote:
> > On 2019-01-25 Adam G=C3=B3rski wrote in comp.arch.fpga:
> > > On 2019-01-25 15:58, Stef wrote:
> > >> Hi,
> > >>=20
> > >> We got an old design with an Altera Cyclone FPGA (EP1C12F324).
> > >> These are probably obsolete (Can't find any info on them on the Inte=
l
> > >> site, Farnell is out of stock, etc.). Currently active are the Cyclo=
ne-IV
> > >> and Cyclone-V if I understood correctly.
> > >>=20
> > >> 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.
> > >>=20
> > >> Or alternatively, are their sources for these old Cyclone chips?
> > >> (We actually would need 3 different types :-( )
> > >>=20
> > >>=20
> > >
> > > Hi,
> > >
> > > Are you looking for somebody who can transfer you project from Altera=
=20
> > > Cyclone to Cyclone V ?
> >=20
> > Not for now, but who knows. Will be to Cyclone 10 or Max 10 then after
> > recent discoveries. ;-)
>=20
> If you are porting to a new family, why limit yourself to Cyclones?  If t=
he HDL was written without using specific device features, you can likely p=
ort it as easily to another brand as to a new device.  Xilinx and Lattice a=
nd even Microsemi make competitive FPGAs.  But then I suppose there is a li=
cense 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. =20
>=20
> 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 d=
esign.  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 wh=
o had created a design which needed to be updated.  Seems he had included o=
ne tiny piece that required hand routing in the chip editor to meet the tim=
ing spec... and had not documented this anywhere!!!  So we received a bit o=
f oral tradition.  This company makes test equipment that is sold to all th=
e major comms manufacturers.  lol! =20
>=20
> Given that Altera is now owned by Intel, I would use this opportunity to =
replace the NIOS processor with something independent of device manufacture=
r and remove your brand dependency.  There are tons of third party processo=
rs out there.  I can recommend one if you need.=20
>=20
>=20
>   Rick C.
>=20
>   + 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.  Howeve=
r, after the acquisition in 2016, it appears that Intel halted *everything*=
 in the Altera business and they're still catching up with the rebranding o=
n all of their documentation, website, etc.  Their forums are still a real =
mess, so even searching for solutions is a challenge. =20

For anyone in the same position as the OP, if the sales volumes and the for=
ecast 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 pr=
oof" the design by migrating to another vendor that isn't likely to get acq=
uired 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 over=
kill 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 othe=
r soft core.  The Spartan-7 family is essentially the Artix-7 fabric with t=
he transcievers removed and are offered in 6K to 100K logic cell densities.

Article: 161060
Subject: Re: Altera Cyclone replacement
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 29 Jan 2019 16:57:00 -0800 (PST)
Links: << >>  << T >>  << A >>
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 migrat=
ing to another vendor that isn't likely to get acquired or axed.  Xilinx ha=
s the single core Zynq-7000 devices if you want to go with a more main-stre=
am, ARM processor sub-system (although likely overkill for whatever your Ni=
os is doing).  Otherwise, the Artix-7 and Spartan-7 would be good targets i=
f 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 a=
nd 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 Mi=
croBlaze processor isn't "future proofing" anything.  It is just shifting f=
rom one brand to another with the exact same problems. =20

If you want to future proof a soft CPU design you need to drop any FPGA com=
pany in-house processor and use an open source processor design.  Then you =
can use any FPGA you wish. =20

Here is some info on the J1, an open source processor that was used to repl=
ace a microblaze when it became unequal to the task at hand. =20

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

Article: 161061
Subject: Re: Altera Cyclone replacement
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Wed, 30 Jan 2019 09:33:35 +0100
Links: << >>  << T >>  << A >>
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.

Article: 161062
Subject: Re: Altera Cyclone replacement
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 30 Jan 2019 05:23:11 -0800 (PST)
Links: << >>  << T >>  << A >>
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:
> >>=20
> >> 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. =20
>=20
> I was under the assumption that porting to Cyclones would be less work th=
an
> moving to other families/manufacturers. And I think that is still the cas=
e
> if NIOS is part of the existing design.
>=20
> 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 r=
eal time to be much greater than the issues of fitting a design into an FPG=
A.  People cite all sorts of "facts" about using FPGAs that don't seem to a=
pply in my designs, so I'm not sure what they are doing wrong.  I find FPGA=
s to be easy to design and work with.  I also find much fewer problems on t=
he lab bench and in the field than others do with software based designs. =
=20

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 d=
ays.  EOL devices are popular targets.=20


  Rick C.

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

Article: 161063
Subject: Re: Altera Cyclone replacement
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Wed, 30 Jan 2019 08:24:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail.com w=
rote:
> 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 migr=
ating 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-st=
ream, 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 Spart=
an-7 family is essentially the Artix-7 fabric with the transcievers removed=
 and are offered in 6K to 100K logic cell densities.
>=20
> 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. =20
>=20
> If you want to future proof a soft CPU design you need to drop any FPGA c=
ompany in-house processor and use an open source processor design.  Then yo=
u can use any FPGA you wish. =20
>=20
> Here is some info on the J1, an open source processor that was used to re=
place a microblaze when it became unequal to the task at hand. =20
>=20
> http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
>=20
> http://www.excamera.com/sphinx/fpga-j1.html
>=20
> http://www.excamera.com/files/j1.pdf
>=20
>=20
>   Rick C.
>=20
>   -- 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 recommendati=
on:  "or some other soft core."

If the original Nios was employed, I'm not entirely convinced a soft core i=
s necessary (yet).  How simple is the software running on it?  Can it reaso=
nably 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 tech=
nologies (e.g., old Cyclone and Nios) and the desire is to add more feature=
s that are realizable with new generation devices and soft (or hard) core c=
apabilities.

Article: 161064
Subject: ARM + FPGA CPU Module running Yocto Linux?
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Wed, 30 Jan 2019 18:13:26 +0100
Links: << >>  << T >>  << A >>
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller 
access.

I.E:
     You can write to a register over SPI by:
       FPGA_REGISTER = value;
     instead of

     spi_packet = {
            .cmd = SPI_WRITE,
            .addr = FPGA_REGISTER,
            .size = sizeof(value),
            .data = &value
     }
     spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

Article: 161065
Subject: Re: Altera Cyclone replacement
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 30 Jan 2019 09:14:22 -0800 (PST)
Links: << >>  << T >>  << A >>
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 mi=
grating to another vendor that isn't likely to get acquired or axed.  Xilin=
x 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 you=
r Nios is doing).  Otherwise, the Artix-7 and Spartan-7 would be good targe=
ts if you want to migrate to a Microblaze or some other soft core.  The Spa=
rtan-7 family is essentially the Artix-7 fabric with the transcievers remov=
ed and are offered in 6K to 100K logic cell densities.
> >=20
> > 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 shifti=
ng from one brand to another with the exact same problems. =20
> >=20
> > 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. =20
> >=20
> > 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. =20
> >=20
> > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
> >=20
> > http://www.excamera.com/sphinx/fpga-j1.html
> >=20
> > http://www.excamera.com/files/j1.pdf
> >=20
> >=20
> >   Rick C.
> >=20
> >   -- Get 6 months of free supercharging
> >   -- Tesla referral code - https://ts.la/richard11209
>=20
> No, I got your point perfectly, hence the following part of my recommenda=
tion:  "or some other soft core."

I am making the point that porting from one proprietary processor to anothe=
r is of limited value.  Microblaze is proprietary.  I believe there may be =
some open source versions available, but I expect there are open source ver=
sions of the NIOS available as well.  But perhaps more importantly, they ar=
e 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. =20


> 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 rea=
sonably be ported to HDL, thus ensuring portability?  I tend to lean that w=
ay unless the SW was simple due to capability limitations in the earlier te=
chnologies (e.g., old Cyclone and Nios) and the desire is to add more featu=
res 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 the=
y are added because of the complexity of expression.  Regardless of how sim=
ply 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, i=
t won't get ported to HDL without a compelling reason.=20

Personally I think Xilinx and Altera are responsible for the present percep=
tion that FPGAs are difficult to use, expensive, large and power hungry.  T=
hat is largely true if you use their products only.  Lattice has been addre=
ssing a newer market with small, low power, inexpensive devices intended fo=
r the mobile market.  Now if someone would approach the issue of ease of us=
e 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. =
=20

Does anyone really think toasters can only be controlled by MCUs?  We just =
need a cheap enough FPGA in a suitable package. =20


  Rick C.

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

Article: 161066
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 30 Jan 2019 09:28:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
> Is there any ARM + FPGA CPU Module running linux using any of:
> 
> * NXP i.MX6/7/...
> * Texas Instrument Sitara AM335x or better
> * Microchip SAMA5
> * Renesas RZ/xxx
> 
> It needs to be connected to a low price FPGA, Intel or Xilinx.
> 
> * Zynq or Intel SoC solutions need not apply.
> 
> Other vendors will be difficult to accept.
> 
> =====================
> 
> The CPU Module needs at least
> * 128 MB RAM
> * 128 MB Flash.
> Connector will have
> * 100 Mbps Ethernet
> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
> * SD-Card
> * A few custom protocol LVDS channels
> =====================
> The processor has to be connected to an FPGA on a suitable
> interface providing 5-10 MB/second transfer rate.
> The FPGA needs to have 80-100 free I/O, not including the
> interface to the CPU to implement SPIs, UARTs and other custom signals
> =====================
> The CPU should be able to load the FPGA after reset.
> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
> =====================
> Preferably, the processor should be able to access the internals
> of the FPGA like it was on the memory bus.
> 
> Putting the FPGA on a 16 bit memory interface will work
> 
> Some chip support a transparent mode where you do a memory read/write
> which gets translated to a Quad SPI access, or a NAND flash controller 
> access.
> 
> I.E:
>      You can write to a register over SPI by:
>        FPGA_REGISTER = value;
>      instead of
> 
>      spi_packet = {
>             .cmd = SPI_WRITE,
>             .addr = FPGA_REGISTER,
>             .size = sizeof(value),
>             .data = &value
>      }
>      spi_transfer(&spi_packet);
> 
> 
> We plan to use Yocto for developing Linux, so any Yocto solution
> would be appreciated.
> 
> Looking forward to ideas.
> 
> AP

I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid.  Care you share the rational for not using those obvious solutions?  

You don't indicate what your outline size requirements are.  Would you consider a daughter board mounted on something like a Beagle board?  What sort of quantities would you be expecting to buy? 


  Rick C.

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

Article: 161067
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: lasselangwadtchristensen@gmail.com
Date: Wed, 30 Jan 2019 09:44:55 -0800 (PST)
Links: << >>  << T >>  << A >>
onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
> Is there any ARM + FPGA CPU Module running linux using any of:
> 
> * NXP i.MX6/7/...
> * Texas Instrument Sitara AM335x or better
> * Microchip SAMA5
> * Renesas RZ/xxx
> 
> It needs to be connected to a low price FPGA, Intel or Xilinx.
> 
> * Zynq or Intel SoC solutions need not apply.
> 
> Other vendors will be difficult to accept.
> 
> =====================
> 
> The CPU Module needs at least
> * 128 MB RAM
> * 128 MB Flash.
> Connector will have
> * 100 Mbps Ethernet
> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
> * SD-Card
> * A few custom protocol LVDS channels
> =====================
> The processor has to be connected to an FPGA on a suitable
> interface providing 5-10 MB/second transfer rate.
> The FPGA needs to have 80-100 free I/O, not including the
> interface to the CPU to implement SPIs, UARTs and other custom signals
> =====================
> The CPU should be able to load the FPGA after reset.
> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
> =====================
> Preferably, the processor should be able to access the internals
> of the FPGA like it was on the memory bus.
> 
> Putting the FPGA on a 16 bit memory interface will work
> 
> Some chip support a transparent mode where you do a memory read/write
> which gets translated to a Quad SPI access, or a NAND flash controller 
> access.
> 
> I.E:
>      You can write to a register over SPI by:
>        FPGA_REGISTER = value;
>      instead of
> 
>      spi_packet = {
>             .cmd = SPI_WRITE,
>             .addr = FPGA_REGISTER,
>             .size = sizeof(value),
>             .data = &value
>      }
>      spi_transfer(&spi_packet);
> 
> 
> We plan to use Yocto for developing Linux, so any Yocto solution
> would be appreciated.
> 
> Looking forward to ideas.
> 
> AP

why not Zynq? it has everything you ask for and the same ARM-9 as the NXP

Article: 161068
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Wed, 30 Jan 2019 19:21:22 +0100
Links: << >>  << T >>  << A >>
Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen@gmail.com:
> onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
>> Is there any ARM + FPGA CPU Module running linux using any of:
>>
>> * NXP i.MX6/7/...
>> * Texas Instrument Sitara AM335x or better
>> * Microchip SAMA5
>> * Renesas RZ/xxx
>>
>> It needs to be connected to a low price FPGA, Intel or Xilinx.
>>
>> * Zynq or Intel SoC solutions need not apply.
>>
>> Other vendors will be difficult to accept.
>>
>> =====================
>>
>> The CPU Module needs at least
>> * 128 MB RAM
>> * 128 MB Flash.
>> Connector will have
>> * 100 Mbps Ethernet
>> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
>> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
>> * SD-Card
>> * A few custom protocol LVDS channels
>> =====================
>> The processor has to be connected to an FPGA on a suitable
>> interface providing 5-10 MB/second transfer rate.
>> The FPGA needs to have 80-100 free I/O, not including the
>> interface to the CPU to implement SPIs, UARTs and other custom signals
>> =====================
>> The CPU should be able to load the FPGA after reset.
>> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
>> =====================
>> Preferably, the processor should be able to access the internals
>> of the FPGA like it was on the memory bus.
>>
>> Putting the FPGA on a 16 bit memory interface will work
>>
>> Some chip support a transparent mode where you do a memory read/write
>> which gets translated to a Quad SPI access, or a NAND flash controller
>> access.
>>
>> I.E:
>>       You can write to a register over SPI by:
>>         FPGA_REGISTER = value;
>>       instead of
>>
>>       spi_packet = {
>>              .cmd = SPI_WRITE,
>>              .addr = FPGA_REGISTER,
>>              .size = sizeof(value),
>>              .data = &value
>>       }
>>       spi_transfer(&spi_packet);
>>
>>
>> We plan to use Yocto for developing Linux, so any Yocto solution
>> would be appreciated.
>>
>> Looking forward to ideas.
>>
>> AP
> 
> why not Zynq? it has everything you ask for and the same ARM-9 as the NXP
> 

Because it is way too expensive.

You can get a better ARM chip for $6-7 in 1k qty.
A Cyclone 10 FPGA is $8-9.
Can You get a Zynq for $14-16 in 1k volume?
Digikey shows one off pricing for the cheapest Zynq to be $46.
If they can give 40% discount at 1k, it is still $30 = 2x price.


Another thing is that the onboard peripherals generally suck.
At least when I looked at them the last time.
I do not care to waste my time on why.

This means that we have to spend time doing peripherals in the FPGA.
They need to be supported by Linux drivers.
We do not want to add that development effort.

AP

Article: 161069
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Wed, 30 Jan 2019 19:28:35 +0100
Links: << >>  << T >>  << A >>
Den 2019-01-30 kl. 18:28, skrev gnuarm.deletethisbit@gmail.com:
> On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
>> Is there any ARM + FPGA CPU Module running linux using any of:
>>
>> * NXP i.MX6/7/...
>> * Texas Instrument Sitara AM335x or better
>> * Microchip SAMA5
>> * Renesas RZ/xxx
>>
>> It needs to be connected to a low price FPGA, Intel or Xilinx.
>>
>> * Zynq or Intel SoC solutions need not apply.
>>
>> Other vendors will be difficult to accept.
>>
>> =====================
>>
>> The CPU Module needs at least
>> * 128 MB RAM
>> * 128 MB Flash.
>> Connector will have
>> * 100 Mbps Ethernet
>> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
>> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
>> * SD-Card
>> * A few custom protocol LVDS channels
>> =====================
>> The processor has to be connected to an FPGA on a suitable
>> interface providing 5-10 MB/second transfer rate.
>> The FPGA needs to have 80-100 free I/O, not including the
>> interface to the CPU to implement SPIs, UARTs and other custom signals
>> =====================
>> The CPU should be able to load the FPGA after reset.
>> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
>> =====================
>> Preferably, the processor should be able to access the internals
>> of the FPGA like it was on the memory bus.
>>
>> Putting the FPGA on a 16 bit memory interface will work
>>
>> Some chip support a transparent mode where you do a memory read/write
>> which gets translated to a Quad SPI access, or a NAND flash controller
>> access.
>>
>> I.E:
>>       You can write to a register over SPI by:
>>         FPGA_REGISTER = value;
>>       instead of
>>
>>       spi_packet = {
>>              .cmd = SPI_WRITE,
>>              .addr = FPGA_REGISTER,
>>              .size = sizeof(value),
>>              .data = &value
>>       }
>>       spi_transfer(&spi_packet);
>>
>>
>> We plan to use Yocto for developing Linux, so any Yocto solution
>> would be appreciated.
>>
>> Looking forward to ideas.
>>
>> AP
> 
> I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid.  Care you share the rational for not using those obvious solutions?
> 
> You don't indicate what your outline size requirements are.  Would you consider a daughter board mounted on something like a Beagle board?  What sort of quantities would you be expecting to buy?
> 

We will do a base board, for which we need a CPU+FPGA module, so no 
adding two boards together.

We are looking for an existing board for some prototyping.
Not having someone design it for us. A few boards will be OK.

Ideally, the module would have a suitable connector that
can be used, or if not, it would be good to have a schematic
that can be used to design our own physical format.

Volume for the end product is 1k/year, but we expect the production
to be long lifed.

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


Article: 161070
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 30 Jan 2019 10:29:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, January 30, 2019 at 1:21:30 PM UTC-5, A.P.Richelieu wrote:
> Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen@gmail.com:
> > onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
> >> Is there any ARM + FPGA CPU Module running linux using any of:
> >>
> >> * NXP i.MX6/7/...
> >> * Texas Instrument Sitara AM335x or better
> >> * Microchip SAMA5
> >> * Renesas RZ/xxx
> >>
> >> It needs to be connected to a low price FPGA, Intel or Xilinx.
> >>
> >> * Zynq or Intel SoC solutions need not apply.
> >>
> >> Other vendors will be difficult to accept.
> >>
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> The CPU Module needs at least
> >> * 128 MB RAM
> >> * 128 MB Flash.
> >> Connector will have
> >> * 100 Mbps Ethernet
> >> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
> >> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
> >> * SD-Card
> >> * A few custom protocol LVDS channels
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> The processor has to be connected to an FPGA on a suitable
> >> interface providing 5-10 MB/second transfer rate.
> >> The FPGA needs to have 80-100 free I/O, not including the
> >> interface to the CPU to implement SPIs, UARTs and other custom signals
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> The CPU should be able to load the FPGA after reset.
> >> Preferably right after loading the U-Boot (during the BOOTDELAY timer)=
.
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> Preferably, the processor should be able to access the internals
> >> of the FPGA like it was on the memory bus.
> >>
> >> Putting the FPGA on a 16 bit memory interface will work
> >>
> >> Some chip support a transparent mode where you do a memory read/write
> >> which gets translated to a Quad SPI access, or a NAND flash controller
> >> access.
> >>
> >> I.E:
> >>       You can write to a register over SPI by:
> >>         FPGA_REGISTER =3D value;
> >>       instead of
> >>
> >>       spi_packet =3D {
> >>              .cmd =3D SPI_WRITE,
> >>              .addr =3D FPGA_REGISTER,
> >>              .size =3D sizeof(value),
> >>              .data =3D &value
> >>       }
> >>       spi_transfer(&spi_packet);
> >>
> >>
> >> We plan to use Yocto for developing Linux, so any Yocto solution
> >> would be appreciated.
> >>
> >> Looking forward to ideas.
> >>
> >> AP
> >=20
> > why not Zynq? it has everything you ask for and the same ARM-9 as the N=
XP
> >=20
>=20
> Because it is way too expensive.
>=20
> You can get a better ARM chip for $6-7 in 1k qty.
> A Cyclone 10 FPGA is $8-9.
> Can You get a Zynq for $14-16 in 1k volume?
> Digikey shows one off pricing for the cheapest Zynq to be $46.
> If they can give 40% discount at 1k, it is still $30 =3D 2x price.
>=20
>=20
> Another thing is that the onboard peripherals generally suck.
> At least when I looked at them the last time.
> I do not care to waste my time on why.
>=20
> This means that we have to spend time doing peripherals in the FPGA.
> They need to be supported by Linux drivers.
> We do not want to add that development effort.


It is hard to know what you really need and what you may have prematurely d=
iscounted from what you post above.  You say you need peripherals with Linu=
x drivers, but you didn't indicate much in your original post other than va=
rious peripherals you plan to mostly implement in the FPGA. =20

So even with the separate CPU and FPGA approach how can anyone recommend a =
solution when we don't know all the requirements?=20

One thing I do know is that the FPGA vendors will provide some amazingly go=
od prices if you can commit to quantities they care about.  They want to ta=
lk to you in person and are happy to do so.  That's why Digikey doesn't hav=
e qty 1k pricing.  Set up some lunch dates and let Xilinx and Intel take yo=
u to lunch.  They are often happy to do that.  They've done it with me.=20


  Rick C.

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

Article: 161071
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: Theo <theom+news@chiark.greenend.org.uk>
Date: 30 Jan 2019 18:49:01 +0000 (GMT)
Links: << >>  << T >>  << A >>
A.P.Richelieu <aprichelieu@gmail.com> wrote:
> You can get a better ARM chip for $6-7 in 1k qty.
> A Cyclone 10 FPGA is $8-9.
> Can You get a Zynq for $14-16 in 1k volume?
> Digikey shows one off pricing for the cheapest Zynq to be $46.
> If they can give 40% discount at 1k, it is still $30 = 2x price.

Bear in mind that on a daughterboard you have to pay for
ARM+FPGA+DRAM+storage+PCB+connectors+vendor profit.

If you're doing a Zynq/CycloneSoC you're paying for
Zynq+DRAM+storage

It's not immediately clear that you're going to win by buying a third-party
board, especially one where you want security of supply (so no random China
board).

I could see it swing towards the daughterboard approach if this means you
can get away with a cheaper PCB (no BGAs, DDR routing).  I'm not sure if the
power supply arrangements would be simpler too.

> Another thing is that the onboard peripherals generally suck.
> At least when I looked at them the last time.
> I do not care to waste my time on why.

You mean the hard peripherals (ethernet, USB, SD, etc), usually Synopsys IP
as found in other SoCs?  Or the Xilinx/Intel soft peripherals?

> This means that we have to spend time doing peripherals in the FPGA.
> They need to be supported by Linux drivers.
> We do not want to add that development effort.

AFAICS some of your requirements (100M ethernet, SD) will be hard logic on
Zynq or Cyclone.  The others (12 SPI channels, 5 UARTs) will have to be soft
logic, at which point the driver situation is more or less the same
whichever platform you pick.

Theo

Article: 161072
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Wed, 30 Jan 2019 19:52:38 +0100
Links: << >>  << T >>  << A >>
Den 2019-01-30 kl. 19:29, skrev gnuarm.deletethisbit@gmail.com:
> On Wednesday, January 30, 2019 at 1:21:30 PM UTC-5, A.P.Richelieu wrote:
>> Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen@gmail.com:
>>> onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
>>>> Is there any ARM + FPGA CPU Module running linux using any of:
>>>>
>>>> * NXP i.MX6/7/...
>>>> * Texas Instrument Sitara AM335x or better
>>>> * Microchip SAMA5
>>>> * Renesas RZ/xxx
>>>>
>>>> It needs to be connected to a low price FPGA, Intel or Xilinx.
>>>>
>>>> * Zynq or Intel SoC solutions need not apply.
>>>>
>>>> Other vendors will be difficult to accept.
>>>>
>>>> =====================
>>>>
>>>> The CPU Module needs at least
>>>> * 128 MB RAM
>>>> * 128 MB Flash.
>>>> Connector will have
>>>> * 100 Mbps Ethernet
>>>> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
>>>> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
>>>> * SD-Card
>>>> * A few custom protocol LVDS channels
>>>> =====================
>>>> The processor has to be connected to an FPGA on a suitable
>>>> interface providing 5-10 MB/second transfer rate.
>>>> The FPGA needs to have 80-100 free I/O, not including the
>>>> interface to the CPU to implement SPIs, UARTs and other custom signals
>>>> =====================
>>>> The CPU should be able to load the FPGA after reset.
>>>> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
>>>> =====================
>>>> Preferably, the processor should be able to access the internals
>>>> of the FPGA like it was on the memory bus.
>>>>
>>>> Putting the FPGA on a 16 bit memory interface will work
>>>>
>>>> Some chip support a transparent mode where you do a memory read/write
>>>> which gets translated to a Quad SPI access, or a NAND flash controller
>>>> access.
>>>>
>>>> I.E:
>>>>        You can write to a register over SPI by:
>>>>          FPGA_REGISTER = value;
>>>>        instead of
>>>>
>>>>        spi_packet = {
>>>>               .cmd = SPI_WRITE,
>>>>               .addr = FPGA_REGISTER,
>>>>               .size = sizeof(value),
>>>>               .data = &value
>>>>        }
>>>>        spi_transfer(&spi_packet);
>>>>
>>>>
>>>> We plan to use Yocto for developing Linux, so any Yocto solution
>>>> would be appreciated.
>>>>
>>>> Looking forward to ideas.
>>>>
>>>> AP
>>>
>>> why not Zynq? it has everything you ask for and the same ARM-9 as the NXP
>>>
>>
>> Because it is way too expensive.
>>
>> You can get a better ARM chip for $6-7 in 1k qty.
>> A Cyclone 10 FPGA is $8-9.
>> Can You get a Zynq for $14-16 in 1k volume?
>> Digikey shows one off pricing for the cheapest Zynq to be $46.
>> If they can give 40% discount at 1k, it is still $30 = 2x price.
>>
>>
>> Another thing is that the onboard peripherals generally suck.
>> At least when I looked at them the last time.
>> I do not care to waste my time on why.
>>
>> This means that we have to spend time doing peripherals in the FPGA.
>> They need to be supported by Linux drivers.
>> We do not want to add that development effort.
> 
> 
> It is hard to know what you really need and what you may have prematurely discounted from what you post above.  You say you need peripherals with Linux drivers, but you didn't indicate much in your original post other than various peripherals you plan to mostly implement in the FPGA.
> 
> So even with the separate CPU and FPGA approach how can anyone recommend a solution when we don't know all the requirements?
> 
> One thing I do know is that the FPGA vendors will provide some amazingly good prices if you can commit to quantities they care about.  They want to talk to you in person and are happy to do so.  That's why Digikey doesn't have qty 1k pricing.  Set up some lunch dates and let Xilinx and Intel take you to lunch.  They are often happy to do that.  They've done it with me.
> 
We are using the Zynq in other places, so the decision has been made to 
skip it for this project due to price, but mostly because of the periperals.

I have stated my needs.
=========================
A CPU + FPGA combination.
5-10 MB/s connection to the FPGA
80-100 FPGA I/O, some with LVDS.
Memory needs
An existing board with decent Linux support.
It should not be based on Zync or SoC.
The ARM chips should be from the vendors above.


Exactly what we intend to do with the FPGA is not something I can 
comment. And it is not worthwhile to enter a discussion why a Zynq or 
SoC should fit, that train has left.

An example of something that almost works is
https://www.embeddedarm.com/products/TS-4100

This has everything, except a slow interface to the FPGA.
The MACH series is a little small though.
A Cyclone 10 or Spartan 6 are probably the minimum
level FPGA we are looking for.

https://www.embeddedarm.com/products/TS-4740
Seems to have a nice interface, but the Marvell processor is a no,no.

AP

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


Article: 161073
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de>
Date: Wed, 30 Jan 2019 19:53:33 +0100
Links: << >>  << T >>  << A >>
Am 30.01.19 um 19:21 schrieb A.P.Richelieu:
> Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen@gmail.com:
>> onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
>>> Is there any ARM + FPGA CPU Module running linux using any of:
>>>
>>> * NXP i.MX6/7/...
>>> * Texas Instrument Sitara AM335x or better
>>> * Microchip SAMA5
>>> * Renesas RZ/xxx
>>>
>>> It needs to be connected to a low price FPGA, Intel or Xilinx.
>>>
>>> * Zynq or Intel SoC solutions need not apply.
>>>
>>> Other vendors will be difficult to accept.
>>>
>>> =====================
>>>
>>> The CPU Module needs at least
>>> * 128 MB RAM
>>> * 128 MB Flash.
>>> Connector will have
>>> * 100 Mbps Ethernet
>>> * 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
>>> * 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
>>> * SD-Card
>>> * A few custom protocol LVDS channels
>>> =====================
>>> The processor has to be connected to an FPGA on a suitable
>>> interface providing 5-10 MB/second transfer rate.
>>> The FPGA needs to have 80-100 free I/O, not including the
>>> interface to the CPU to implement SPIs, UARTs and other custom signals
>>> =====================
>>> The CPU should be able to load the FPGA after reset.
>>> Preferably right after loading the U-Boot (during the BOOTDELAY timer).
>>> =====================
>>> Preferably, the processor should be able to access the internals
>>> of the FPGA like it was on the memory bus.
>>>
>>> Putting the FPGA on a 16 bit memory interface will work
>>>

The BeagleBoneBlack has at least a 16 bit multiplexed data bus, even
when it shares pins with other stuff.

I'm looking into that because I want a FPGA that has support
for some JESDI204B lanes to connect to some contemporary ADCs and DACs.

And on-chip CPUs have been a royal pain from Power-PC to Picoblaze.
I like it when I know that at least my Linux runs stable, so bugs
must be in user land or the hardware - and not in my driver that
kills my ssh access.

It found it quite OK to run the time-critical stuff on a PRU and
just hand the Linux-ARM the time-decoupled data via shared buffers.
There is a C compiler for the PRUs in the standard BBB Linux distribution.

regards,
Gerhard

Article: 161074
Subject: Re: ARM + FPGA CPU Module running Yocto Linux?
From: "A.P.Richelieu" <aprichelieu@gmail.com>
Date: Wed, 30 Jan 2019 19:55:23 +0100
Links: << >>  << T >>  << A >>
Den 2019-01-30 kl. 19:49, skrev Theo:
> A.P.Richelieu <aprichelieu@gmail.com> wrote:
>> You can get a better ARM chip for $6-7 in 1k qty.
>> A Cyclone 10 FPGA is $8-9.
>> Can You get a Zynq for $14-16 in 1k volume?
>> Digikey shows one off pricing for the cheapest Zynq to be $46.
>> If they can give 40% discount at 1k, it is still $30 = 2x price.
> 
> Bear in mind that on a daughterboard you have to pay for
> ARM+FPGA+DRAM+storage+PCB+connectors+vendor profit.
> 
> If you're doing a Zynq/CycloneSoC you're paying for
> Zynq+DRAM+storage
> 
> It's not immediately clear that you're going to win by buying a third-party
> board, especially one where you want security of supply (so no random China
> board).
> 
> I could see it swing towards the daughterboard approach if this means you
> can get away with a cheaper PCB (no BGAs, DDR routing).  I'm not sure if the
> power supply arrangements would be simpler too.
> 
>> Another thing is that the onboard peripherals generally suck.
>> At least when I looked at them the last time.
>> I do not care to waste my time on why.
> 
> You mean the hard peripherals (ethernet, USB, SD, etc), usually Synopsys IP
> as found in other SoCs?  Or the Xilinx/Intel soft peripherals?
> 
>> This means that we have to spend time doing peripherals in the FPGA.
>> They need to be supported by Linux drivers.
>> We do not want to add that development effort.
> 
> AFAICS some of your requirements (100M ethernet, SD) will be hard logic on
> Zynq or Cyclone.  The others (12 SPI channels, 5 UARTs) will have to be soft
> logic, at which point the driver situation is more or less the same
> whichever platform you pick.
> 
> Theo
> 

You are trying to convince me to look at Zynq and SoC.
That is what I explicitly said I was not going to do.

AP



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search