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
2019JanFebMar2019

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 157800

Article: 157800
Subject: Bad condition in wait statement, or only one clock per process.
From: ashwini012 <jagtapashwini08@gmail.com>
Date: Mon, 30 Mar 2015 04:54:12 -0500
Links: << >>  << T >>  << A >>
Hi,
i am working on the following code but i have error as:

"Bad condition in wait statement, or only one clock per process." 

Code:

  Sensor_fusion_1_output : PROCESS 
    VARIABLE z : vector_of_real(0 TO 11);
    VARIABLE xapriori : vector_of_real(0 TO 11);
    VARIABLE residual : vector_of_real(0 TO 11);
    VARIABLE papriori : vector_of_real(0 TO 11);
    VARIABLE K : vector_of_real(0 TO 11);
    VARIABLE paposteriori : vector_of_real(0 TO 11);
    VARIABLE xaposteriori1 : vector_of_real(0 TO 11);
    VARIABLE add_temp : real;
    VARIABLE div_temp : real;
    VARIABLE add_temp_0 : vector_of_real(0 TO 10);
    VARIABLE div_temp_0 : vector_of_real(0 TO 10);

  BEGIN

    z := temp;
    xapriori := (OTHERS => 0.0);
    residual := (OTHERS => 0.0);
    papriori := (OTHERS => 0.0);
    K := (OTHERS => 0.0);
    paposteriori := (OTHERS => 0.0);
    xaposteriori1 := (OTHERS => 0.0);
    xapriori(0) := 0.0;
    residual(0) := z(0);
    papriori(0) := 4.3;
    add_temp := 4.3 + 0.1;
    IF add_temp = 0.0 THEN 
      div_temp := C_divbyzero_p;
    ELSE 
      div_temp := One / add_temp;
    END IF;
    K(0) := div_temp;
    paposteriori(0) := 4.3 * (1.0 - K(0));
    xaposteriori1(0) := K(0) * z(0);
 
    FOR k_0 IN 0 TO 10 LOOP
      xapriori(1 + k_0) := xaposteriori1(k_0);
      residual(1 + k_0) := z(1 + k_0) - xapriori(1 + k_0);
      papriori(1 + k_0) := paposteriori(k_0) + 2.8;
      add_temp_0(k_0) := papriori(1 + k_0) + 0.1;
      IF add_temp_0(k_0) = 0.0 THEN 
        IF (papriori(1 + k_0) < 0.0) XOR (add_temp_0(k_0) < 0.0) THEN 
          div_temp_0(k_0) := C_divbyzero_n;
        ELSE 
          div_temp_0(k_0) := C_divbyzero_p;
        END IF;
      ELSE 
        div_temp_0(k_0) := papriori(1 + k_0) / add_temp_0(k_0);
      END IF;

      K(1 + k_0) := div_temp_0(k_0);
      paposteriori(1 + k_0) := papriori(1 + k_0) * (1.0 - K(1 + k_0));
      xaposteriori1(1 + k_0) := xapriori(1 + k_0) + (K(1 + k_0) * residual(1 + k_0));
    END LOOP;

    xaposteriori <= xaposteriori1;

    WAIT;

  END PROCESS Sensor_fusion_1_output;



Can anyone help me.Please....

Thank you.



Article: 157801
Subject: Re: Bad condition in wait statement, or only one clock per process.
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Mon, 30 Mar 2015 10:19:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Mon, 30 Mar 2015 04:54:12 -0500, ashwini012 wrote:

> Hi,
> i am working on the following code but i have error as:
> 
> "Bad condition in wait statement, or only one clock per process."
> 
> Code:
> 
>   Sensor_fusion_1_output : PROCESS
>     VARIABLE z : vector_of_real(0 TO 11);
...
> 
>   BEGIN
> 
>     z := temp;
> 
>     WAIT;
> 
>   END PROCESS Sensor_fusion_1_output;

> Can anyone help me.Please....
> 
> Thank you.

It would help if you mentioned which tool reported these errors.

I presume you know that this code is for simulation only, and cannot be 
synthesised, right? But I can't see anything wrong with it for 
simulation, other than it will only run once, probably before any other 
signals had valid values.

-- Brian


Article: 157802
Subject: Re: Interpret a VHDL statement within a serial to paralell port
From: nobody <cydrollinger@gmail.com>
Date: Mon, 30 Mar 2015 09:01:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote:
> On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote:
> > On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote:
> >> First, thank you for taking the time to consider the questions I have =
not answered.
> >> I am working on a 32 bit serial to 32 bit parallel port which reads fr=
om an ADC. Currently looking to find a better solution, and I searched for =
predefined vhdl module with little success. I stumbled upon Macros, SR16CE,=
 which utilize primitives but they seem to be schematic oriented and not av=
ailable inside the ISE 8.2i, windows xp os.
> >>
> >> Question: Do common VHDL constructs exist in some library within the X=
ilinx folder file structure?
> >>
> >> Stumbling onto some help files within Xilinx website,http://www.csit-s=
un.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx.c=
om/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was l=
ooking for, however I need some help interpreting the VHDL statement that d=
oes everything, [line 13]:
> >>
> >> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and Par=
allel Out
> >> Note For this example XST will infer SRL16.
> >>
> >> 1.library ieee;
> >> 2.use ieee.std_logic_1164.all;
> >>
> >> 3.entity shift is
> >> 4. port(C, SI : in  std_logic;
> >> 5.        PO : out std_logic_vector(7 downto 0));
> >> 6.end shift;
> >> 7.architecture archi of shift is
> >> 8.  signal tmp: std_logic_vector(7 downto 0);
> >> 9.  begin
> >> 10.    process (C)
> >> 11.      begin
> >> 12.        if (C'event and C=3D'1') then
> >> 13.         tmp <=3D tmp(6 downto 0)& SI;
> >> 14.        end if;
> >> 15.    end process;
> >> 16.    PO <=3D tmp;
> >> 17.end archi;
> >>
> >> Question:How does line 13 seem to do so much?
> >
> > The "&" symbol in Line 13 is the concatenation operator. Line 13 perfor=
ms the shift by concatenating the lower 7 bits of the shift register with t=
he serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 of =
tmp being discarded. Hope this helps.
>=20
> Yes, that is a fairly straightforward expression of the shift function.=
=20
>   The question is whether your tool will be able to infer the use of two=
=20
> SRL16s.  Actually, I don't think an SRL16 is at all appropriate for a=20
> serial to parallel converter since it doesn't have a parallel output.=20
> The SRL16 is serial buffer, 1 bit in and 1 bit out.
>=20
> If you look at the various sections on this page they list examples some=
=20
> of which say they *will* infer SRL16s and some say they *will not* infer=
=20
> SRL16s.  I think they made a mistake and left out the *not* for the=20
> section showing this code.  This is *not* Xilinx vetted info.  It is a=20
> third party source with unknown credentials.  I believe any of the code=
=20
> shown involving parallel input or output will not be inferred using SRL16=
s.
>=20
> Look at this app note and I think you will see the limitation of the=20
> SRL16s.
>=20
> http://www.xilinx.com/support/documentation/application_notes/xapp465.pdf
>=20
> So the above code will work just fine.  It just won't, and in fact,=20
> *can't* use an SRL16.
>=20
> Someone please correct me if I am wrong.
>=20
> --=20
>=20
> Rick

Thank you for you time. I had similar thoughts having read xapp465. I guess=
 that still leaves me with needing a helpful solution toward utilizing a se=
rial to parallel hardware, which would seem very common and tucked away in =
some library somewhere. I came across the use of macros, but are based on g=
raphical symbols, schematics, and not VHDL. The macors seemed to be based o=
n the SR16CE but I have not been able to find hide nor hair of such a beast=
. Thank you!

Article: 157803
Subject: Re: Interpret a VHDL statement within a serial to paralell port
From: nobody <cydrollinger@gmail.com>
Date: Mon, 30 Mar 2015 09:04:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, March 30, 2015 at 9:01:28 AM UTC-7, nobody wrote:
> On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote:
> > On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote:
> > > On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote:
> > >> First, thank you for taking the time to consider the questions I hav=
e not answered.
> > >> I am working on a 32 bit serial to 32 bit parallel port which reads =
from an ADC. Currently looking to find a better solution, and I searched fo=
r predefined vhdl module with little success. I stumbled upon Macros, SR16C=
E, which utilize primitives but they seem to be schematic oriented and not =
available inside the ISE 8.2i, windows xp os.
> > >>
> > >> Question: Do common VHDL constructs exist in some library within the=
 Xilinx folder file structure?
> > >>
> > >> Stumbling onto some help files within Xilinx website,http://www.csit=
-sun.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx=
.com/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was=
 looking for, however I need some help interpreting the VHDL statement that=
 does everything, [line 13]:
> > >>
> > >> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and P=
arallel Out
> > >> Note For this example XST will infer SRL16.
> > >>
> > >> 1.library ieee;
> > >> 2.use ieee.std_logic_1164.all;
> > >>
> > >> 3.entity shift is
> > >> 4. port(C, SI : in  std_logic;
> > >> 5.        PO : out std_logic_vector(7 downto 0));
> > >> 6.end shift;
> > >> 7.architecture archi of shift is
> > >> 8.  signal tmp: std_logic_vector(7 downto 0);
> > >> 9.  begin
> > >> 10.    process (C)
> > >> 11.      begin
> > >> 12.        if (C'event and C=3D'1') then
> > >> 13.         tmp <=3D tmp(6 downto 0)& SI;
> > >> 14.        end if;
> > >> 15.    end process;
> > >> 16.    PO <=3D tmp;
> > >> 17.end archi;
> > >>
> > >> Question:How does line 13 seem to do so much?
> > >
> > > The "&" symbol in Line 13 is the concatenation operator. Line 13 perf=
orms the shift by concatenating the lower 7 bits of the shift register with=
 the serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 o=
f tmp being discarded. Hope this helps.

Darol,

Thank you, that was helpful!

Cy

Article: 157804
Subject: Re: Interpret a VHDL statement within a serial to paralell port
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 30 Mar 2015 17:14:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote:
(snip)

>>> I am working on a 32 bit serial to 32 bit parallel port which 
>>> reads from an ADC.
(snip)

> Yes, that is a fairly straightforward expression of the shift function. 
>  The question is whether your tool will be able to infer the use of two 
> SRL16s.  Actually, I don't think an SRL16 is at all appropriate for a 
> serial to parallel converter since it doesn't have a parallel output. 
> The SRL16 is serial buffer, 1 bit in and 1 bit out.

Yes, but I think you can select which bit it is.

It will at least make constant length shift registers with lengths
other than 16.

The logic is similar to the usual LUT logic, but with the ability
to shift the bits in the LUT (RAM).
 
> If you look at the various sections on this page they list examples some 
> of which say they *will* infer SRL16s and some say they *will not* infer 
> SRL16s.  I think they made a mistake and left out the *not* for the 
> section showing this code.  This is *not* Xilinx vetted info.  It is a 
> third party source with unknown credentials.  I believe any of the code 
> shown involving parallel input or output will not be inferred using SRL16s.

I am not so good at figuring out Xilinx primitives, but I did figure
out how to use a clock generator as a Xilinx primitive.

I think you should be able to generate a shift register, counter, and
multiplexer, to shift and then select which bit to send out.
It might take primitives to do that, though.

-- glen



Article: 157805
Subject: Re: Interpret a VHDL statement within a serial to paralell port
From: rickman <gnuarm@gmail.com>
Date: Mon, 30 Mar 2015 17:50:10 -0400
Links: << >>  << T >>  << A >>
On 3/30/2015 12:01 PM, nobody wrote:
> On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote:
>> On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote:
>>> On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote:
>>>> First, thank you for taking the time to consider the questions I have not answered.
>>>> I am working on a 32 bit serial to 32 bit parallel port which reads from an ADC. Currently looking to find a better solution, and I searched for predefined vhdl module with little success. I stumbled upon Macros, SR16CE, which utilize primitives but they seem to be schematic oriented and not available inside the ISE 8.2i, windows xp os.
>>>>
>>>> Question: Do common VHDL constructs exist in some library within the Xilinx folder file structure?
>>>>
>>>> Stumbling onto some help files within Xilinx website,http://www.csit-sun.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx.com/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was looking for, however I need some help interpreting the VHDL statement that does everything, [line 13]:
>>>>
>>>> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and Parallel Out
>>>> Note For this example XST will infer SRL16.
>>>>
>>>> 1.library ieee;
>>>> 2.use ieee.std_logic_1164.all;
>>>>
>>>> 3.entity shift is
>>>> 4. port(C, SI : in  std_logic;
>>>> 5.        PO : out std_logic_vector(7 downto 0));
>>>> 6.end shift;
>>>> 7.architecture archi of shift is
>>>> 8.  signal tmp: std_logic_vector(7 downto 0);
>>>> 9.  begin
>>>> 10.    process (C)
>>>> 11.      begin
>>>> 12.        if (C'event and C='1') then
>>>> 13.         tmp <= tmp(6 downto 0)& SI;
>>>> 14.        end if;
>>>> 15.    end process;
>>>> 16.    PO <= tmp;
>>>> 17.end archi;
>>>>
>>>> Question:How does line 13 seem to do so much?
>>>
>>> The "&" symbol in Line 13 is the concatenation operator. Line 13 performs the shift by concatenating the lower 7 bits of the shift register with the serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 of tmp being discarded. Hope this helps.
>>
>> Yes, that is a fairly straightforward expression of the shift function.
>>    The question is whether your tool will be able to infer the use of two
>> SRL16s.  Actually, I don't think an SRL16 is at all appropriate for a
>> serial to parallel converter since it doesn't have a parallel output.
>> The SRL16 is serial buffer, 1 bit in and 1 bit out.
>>
>> If you look at the various sections on this page they list examples some
>> of which say they *will* infer SRL16s and some say they *will not* infer
>> SRL16s.  I think they made a mistake and left out the *not* for the
>> section showing this code.  This is *not* Xilinx vetted info.  It is a
>> third party source with unknown credentials.  I believe any of the code
>> shown involving parallel input or output will not be inferred using SRL16s.
>>
>> Look at this app note and I think you will see the limitation of the
>> SRL16s.
>>
>> http://www.xilinx.com/support/documentation/application_notes/xapp465.pdf
>>
>> So the above code will work just fine.  It just won't, and in fact,
>> *can't* use an SRL16.
>>
>> Someone please correct me if I am wrong.
>>
>> --
>>
>> Rick
>
> Thank you for you time. I had similar thoughts having read xapp465. I guess that still leaves me with needing a helpful solution toward utilizing a serial to parallel hardware, which would seem very common and tucked away in some library somewhere. I came across the use of macros, but are based on graphical symbols, schematics, and not VHDL. The macors seemed to be based on the SR16CE but I have not been able to find hide nor hair of such a beast.. Thank you!


I'm not sure what you are trying to do.  The code you have above will do 
the job of a serial to parallel shift register.  Why do you need to 
worry about which primitives get used in the FPGA?

-- 

Rick

Article: 157806
Subject: Re: Intel in Talks to buy Altera
From: Anssi Saari <as@sci.fi>
Date: Tue, 31 Mar 2015 10:30:18 +0300
Links: << >>  << T >>  << A >>
Brian Drummond <brian@shapes.demon.co.uk> writes:

> Well, Intel were Altera's 'second source' (back when that mattered) and 
> (if I'm not mistaken) their original fab back in about 1983 - which is 
> where the "Intel FPGAs" mentioned in another post came from. 
>
> So there's quite a long association there.

Wasn't there also some kind of Intel Atom + Altera FPGA on the same
chip? Ah yes, the
Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969

I guess those weren't huge sellers... But last summer Intel announced
some upcoming Xeons with FPGA logic on board. No doubt targeting the
server markets where FPGA coprocessors have made appearances recently.

Article: 157807
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Tue, 31 Mar 2015 03:51:18 -0400
Links: << >>  << T >>  << A >>
On 3/31/2015 3:30 AM, Anssi Saari wrote:
> Brian Drummond <brian@shapes.demon.co.uk> writes:
>
>> Well, Intel were Altera's 'second source' (back when that mattered) and
>> (if I'm not mistaken) their original fab back in about 1983 - which is
>> where the "Intel FPGAs" mentioned in another post came from.
>>
>> So there's quite a long association there.
>
> Wasn't there also some kind of Intel Atom + Altera FPGA on the same
> chip? Ah yes, the
> Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969
>
> I guess those weren't huge sellers... But last summer Intel announced
> some upcoming Xeons with FPGA logic on board. No doubt targeting the
> server markets where FPGA coprocessors have made appearances recently.

I thought that was two die in the same package, no?  Reading your 
article the term, "system-in-package" indicates multiple die.  It think 
the advantage is in reducing the system size and having a very direct 
connection between the two chips.  Putting them on one die would likely 
make a faster connection possible, but would be much more difficult to 
pair in various combinations.  That's the big reason why FPGA makers 
have resisted for so long incorporating CPUs on the FPGA chip until 
recently.

-- 

Rick

Article: 157808
Subject: Re: Intel in Talks to buy Altera
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Tue, 31 Mar 2015 10:13:30 +0100
Links: << >>  << T >>  << A >>
On 31/03/15 08:30, Anssi Saari wrote:
> Brian Drummond <brian@shapes.demon.co.uk> writes:
>
>> Well, Intel were Altera's 'second source' (back when that mattered) and
>> (if I'm not mistaken) their original fab back in about 1983 - which is
>> where the "Intel FPGAs" mentioned in another post came from.
>>
>> So there's quite a long association there.
>
> Wasn't there also some kind of Intel Atom + Altera FPGA on the same
> chip? Ah yes, the
> Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969
>
> I guess those weren't huge sellers... But last summer Intel announced
> some upcoming Xeons with FPGA logic on board. No doubt targeting the
> server markets where FPGA coprocessors have made appearances recently.


More likely Intel wants to head off the market which has ARM
processor(s) plus custom glue logic. Target: highly-integrated
low-power server farms.


Article: 157809
Subject: Re: Intel in Talks to buy Altera
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Tue, 31 Mar 2015 08:14:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, March 28, 2015 at 3:54:12 AM UTC-4, rickman wrote:
> On 3/28/2015 1:38 AM, Rob Doyle wrote:
> > On 3/27/2015 2:28 PM, Tim Wescott wrote:
> >> On Fri, 27 Mar 2015 14:50:23 -0500, "" wrote:
> >>
> >>> http://www.wsj.com/articles/intel-in-talks-to-buy-altera-1427485172
> >>> ---------------------------------------
> >>> Posted through http://www.FPGARelated.com
> >>
> >> Hmm.  While I have tons of respect for Intel as a company that makes
> >> stuff
> >> that people will buy, I'm old enough to have seen more than one
> >> generation
> >> of Intel embedded processors go by the wayside when the PC market picked
> >> up.
> >>
> >> So I don't trust Intel's attention span vis-a-vis whatever they happen to
> >> think their core business is.  If they kept Altera as an easily-spun-off
> >> business unit, and kept it supported, then I could see them spinning it
> >> off again when the PC market did pick up, or by some miracle they managed
> >> to make cell phone processors that actually worked, or something.
> >>
> >
> > Not just embedded processors...
> >
> > It wouldn't be the first time Intel was in the programmable logic business.
> >
> > http://www.dataman.com/media/datasheet/Intel/5C090.pdf
> > http://www.dataman.com/media/datasheet/Intel/5C060.pdf
> > https://docs.google.com/file/d/0B9rh9tVI0J5mSzhDNUVpeVcyNDA/edit
> >
> > Didn't Altera buy Intel's PLD business back in the '90s???
> >
> > Sorry.   I don't see how this could be a good thing for Altera.
> 
> Yeah, I'm concerned too.  I'm hoping that Altera is big enough that 
> Intel won't want to mess with them and destroy the company.
> 
> I think those data sheets are from the days when dinosaurs roamed the 
> FPGA earth and was Intel's own attempt to enter the market.  I have no 
> idea why they actually bailed.  I can only assume the competition was 
> stiff then with a number of startups including Neocad providing the 
> place and route software for a number of these companies.  Xilinx has 
> said they spend more on software development than they do developing the 
> hardware.  Several of these companies dropped their in house software 
> development due to the huge cost.  Maybe Intel dropped the product line 
> because of it.  But much more recently they were working with a company 
> to produce some much more advanced product which I believe may still be 
> operating using Intel's fab technology, or has it also gone belly up?  I 
> don't recall the name.
> 
> Looks like Intel likes the Altera approach and want to keep it, literally.
> 
> -- 
> 
> Rick

Intel acquired Wind River back in '09 but they've left them alone as a separate entity, so we can only hope they do the same with Altera.

http://www.windriver.com/news/press/pr.html?ID=7081

Article: 157810
Subject: Re: Intel in Talks to buy Altera
From: Anssi Saari <as@sci.fi>
Date: Tue, 31 Mar 2015 23:19:15 +0300
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> I thought that was two die in the same package, no?  Reading your
> article the term, "system-in-package" indicates multiple die.  It
> think the advantage is in reducing the system size and having a very
> direct connection between the two chips.  Putting them on one die
> would likely make a faster connection possible, but would be much more
> difficult to pair in various combinations.  

I agree with the separate die part.

> That's the big reason why FPGA makers have resisted for so long
> incorporating CPUs on the FPGA chip until recently.

Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated PowerPC
cores around a decade ago and I'm pretty sure that was single die. I was
involved in such a project in 2006, Virtex 4 Pro was new then and Virtex
2 Pro came out around 2002 I think (from the data sheet dates).

Altera had a similar thing, Excalibur I think? I have to assume those
weren't big sellers either since they pretty much disappeared.

I have to assume they weren't resisting to offer these. My guess would
be they couldn't offer them at competitive prices. Maybe the new
generation is doing better in that regard.

Article: 157811
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Wed, 01 Apr 2015 01:16:30 -0400
Links: << >>  << T >>  << A >>
On 3/31/2015 4:19 PM, Anssi Saari wrote:
> rickman <gnuarm@gmail.com> writes:
>
>> I thought that was two die in the same package, no?  Reading your
>> article the term, "system-in-package" indicates multiple die.  It
>> think the advantage is in reducing the system size and having a very
>> direct connection between the two chips.  Putting them on one die
>> would likely make a faster connection possible, but would be much more
>> difficult to pair in various combinations.
>
> I agree with the separate die part.
>
>> That's the big reason why FPGA makers have resisted for so long
>> incorporating CPUs on the FPGA chip until recently.
>
> Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated PowerPC
> cores around a decade ago and I'm pretty sure that was single die. I was
> involved in such a project in 2006, Virtex 4 Pro was new then and Virtex
> 2 Pro came out around 2002 I think (from the data sheet dates).

Yeah, they had those and Altera had an ARM and Atmel had a... I think 
maybe an AVR on the die with the FPGA.  But they all let them die rather 
than continue the part in the next generation.  When asked Xilinx people 
in particular (who used to be very vocal in this group... in fact, too 
vocal which is why they aren't here anymore) said the problem was the 
many combinations of CPU, RAM and FPGA that would be required, not to 
mention the packaging.  Seems they don't play the same game the MCU 
makers do who regularly have dozens if not hundreds of combinations of 
any given processor.

Also, this was the era when all FPGAs were power hungry and expensive. 
So yeah, they resisted the rest of the market who would have loved 
*affordable* FPGAs with CPUs.  The FPGA makers could have done it, but 
they chose not to address that market because they were after the *big* 
bucks at the high end.


> Altera had a similar thing, Excalibur I think? I have to assume those
> weren't big sellers either since they pretty much disappeared.
>
> I have to assume they weren't resisting to offer these. My guess would
> be they couldn't offer them at competitive prices. Maybe the new
> generation is doing better in that regard.

I think the difference is that their market is determined by pretty much 
one industry, comms.  When they say they would like to see a part, A and 
X reply, "Will Tuesday be soon enough?"  I expect *that* market reached 
a point where the integrated ARM was powerful enough and needed tightly 
coupled enough that it became a worthwhile part.

I know the FPGA companies have all been chasing the high volume markets 
like automotive and even phones and tablets.  But all of these guys have 
volumes that just don't make sense for FPGAs 99% of the time.  Comms is 
where the FPGA profit is and will be for some time to come.

-- 

Rick

Article: 157812
Subject: Re: looking for systemC/TLM 2.0 courses
From: "" <93490@FPGARelated>
Date: Wed, 01 Apr 2015 00:26:30 -0500
Links: << >>  << T >>  << A >>
>>Hi everyone,
>>
>>I apologize if this is maybe not the best audience for these kind of 
>>enquiries but I'll try anyhow.
>>
>>I'm looking for a good SystemC/TLM 2.0 training course which is not too 
>>basic and can give me a head start for a real life project.
>>
>>I'm not a black belt on C++ but I'm familiar with most of its concepts 
>>on top of C (which I use quite often instead). Since we have a budget 
>>for training in our company I'd like to make something useful out of it 
>>and given the current issues we are facing in architecting systems of 
>>increasingly complex features set, I believe that modeling would add 
>>value to our products and avoid many issues due to a wrong architecture.
>>
>>Any ideas/suggestions?
>>
>>p.s.: I've no problems to start some reading/testing by myself in order 
>>to fill the gap before attending the course.
>>
>>-- 
>>A: Because it messes up the order in which people normally read text.
>>Q: Why is top-posting such a bad thing?
>>A: Top-posting.
>>Q: What is the most annoying thing on usenet and in e-mail?
>
>-------------------------------------------------
>You may want to take a look on these simple systemc examples:
>My First systemC program
>systemC debug with SC_TIME Tip
>Simple multiplier and a test-bench in systemC
>ETHERNET packet scv RANDOMIZATION in systemC
>http://bknpk.ddns.net/my_web/MiscellaneousHW/MiscellaneousHW.html
>
>
>---------------------------------------
>Posted through http://www.FPGARelated.com

I recently studied the simple_bus example from systemc. It has not been
converted to TLM, but still is a good example. To compile and run it, you
may want to take a look at:
http://bknpk.ddns.net/my_web/SystemC_MyFirst/sysc_simple_bus_Makefile.html
Another issue that may interest you is SCV. It allows to write constraints
in a system verilog style:
  SCV_CONSTRAINT_CTOR(my_constraint) {
    SCV_CONSTRAINT ( a() * a() + b() * b() == c() * c());
    SCV_CONSTRAINT( a() > 0 && b() > 0 );
  }
A simple example as well as makefile for compilation can be seen at:
http://bknpk.ddns.net/my_web/SystemC_MyFirst/scv_cmp_err_pop_constraint.html
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 157813
Subject: Re: Intel in Talks to buy Altera
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 01 Apr 2015 11:25:59 -0500
Links: << >>  << T >>  << A >>
On Wed, 01 Apr 2015 01:16:30 -0400, rickman wrote:

> On 3/31/2015 4:19 PM, Anssi Saari wrote:
>> rickman <gnuarm@gmail.com> writes:
>>
>>> I thought that was two die in the same package, no?  Reading your
>>> article the term, "system-in-package" indicates multiple die.  It
>>> think the advantage is in reducing the system size and having a very
>>> direct connection between the two chips.  Putting them on one die
>>> would likely make a faster connection possible, but would be much more
>>> difficult to pair in various combinations.
>>
>> I agree with the separate die part.
>>
>>> That's the big reason why FPGA makers have resisted for so long
>>> incorporating CPUs on the FPGA chip until recently.
>>
>> Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated
>> PowerPC cores around a decade ago and I'm pretty sure that was single
>> die. I was involved in such a project in 2006, Virtex 4 Pro was new
>> then and Virtex 2 Pro came out around 2002 I think (from the data sheet
>> dates).
> 
> Yeah, they had those and Altera had an ARM and Atmel had a... I think
> maybe an AVR on the die with the FPGA.  But they all let them die rather
> than continue the part in the next generation.

<balance snipped>

I was on a project that gave those parts a serious look.  We ended up 
using a plain old FPGA talking to a processor.  Partially this was because 
we had a ton of boards that were all using that same processor but without 
the FPGA, but partially this was because we didn't see a great big 
advantage in terms of project hours to the embedded processor.

I have thought for a long time that instead of hugely complicated, 
specialized peripherals, a chip that has a processor with an FPGA mapped 
to the peripheral space could have some use -- it seems like you never 
have the peripherals you'd really like, unless you have a whole bunch of 
peripherals just sitting there sleeping.  There's probably a ton of 
practical reasons why it's a dumb idea.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 157814
Subject: Re: Intel in Talks to buy Altera
From: John Speth <johnspeth@yahoo.com>
Date: Wed, 01 Apr 2015 10:27:27 -0700
Links: << >>  << T >>  << A >>
> I have thought for a long time that instead of hugely complicated,
> specialized peripherals, a chip that has a processor with an FPGA mapped
> to the peripheral space could have some use -- it seems like you never
> have the peripherals you'd really like, unless you have a whole bunch of
> peripherals just sitting there sleeping.  There's probably a ton of
> practical reasons why it's a dumb idea.

There are two popular products on both ends of the spectrum that have 
been around for years: microcontrollers with programmable logic 
peripherals (for example, Cypress PSOC) and a microcontroller core 
implemented on an FPGA (for example, Altera NIOS).

I've used both example products with great success.  As you said, it's 
real convenient to roll your own peripherals with impunity.  It saved me 
hours of coding effort when you can smartly implement the peripheral of 
your dreams with a little HW design.

JJS


Article: 157815
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Wed, 01 Apr 2015 19:10:55 -0400
Links: << >>  << T >>  << A >>
On 4/1/2015 1:27 PM, John Speth wrote:
>> I have thought for a long time that instead of hugely complicated,
>> specialized peripherals, a chip that has a processor with an FPGA mapped
>> to the peripheral space could have some use -- it seems like you never
>> have the peripherals you'd really like, unless you have a whole bunch of
>> peripherals just sitting there sleeping.  There's probably a ton of
>> practical reasons why it's a dumb idea.
>
> There are two popular products on both ends of the spectrum that have
> been around for years: microcontrollers with programmable logic
> peripherals (for example, Cypress PSOC) and a microcontroller core
> implemented on an FPGA (for example, Altera NIOS).

Calling the PSOC circuitry "programmable logic" is a bit of a stretch. 
Yeah, I guess technically it is logic and it is "programmable", but it 
is not at all general purpose.  In some devices it has been dumbed down 
to the point of being configurable serial devices that can be a UART, 
SPI or similar devices, sort of a super USART... not really much like 
FPGAs or even PLDs.  Even the parts that have some programmable elements 
are not terribly flexible.


> I've used both example products with great success.  As you said, it's
> real convenient to roll your own peripherals with impunity.  It saved me
> hours of coding effort when you can smartly implement the peripheral of
> your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that 
they are large, pricey FPGAs and incorporate fairly high end CPUs which 
are typically programmed under Linux...  a very far cry from the 
efficient solution I would like to see.  There are few engineers who can 
even design the entire system on that chip spanning logic design and 
system programming.

-- 

Rick

Article: 157816
Subject: Re: Intel in Talks to buy Altera
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Wed, 1 Apr 2015 23:27:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

> On 4/1/2015 1:27 PM, John Speth wrote:

>> I've used both example products with great success.  As you said, it's
>> real convenient to roll your own peripherals with impunity.  It saved
>> me hours of coding effort when you can smartly implement the peripheral
>> of your dreams with a little HW design.
> 
> The part that gets me about the newer versions of this theme is that
> they are large, pricey FPGAs and incorporate fairly high end CPUs which
> are typically programmed under Linux...  a very far cry from the
> efficient solution I would like to see.  There are few engineers who can
> even design the entire system on that chip spanning logic design and
> system programming.

Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of 
which have big monster Cortex A9s meant to run Linux with a mess of DRAM 
and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT 
FPGA with a dual or quad Cortex M4 instead?  Nice and light with every 
intention of running bare metal with 10-20K of code?  I'd take it in a 
heartbeat.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157817
Subject: Re: Intel in Talks to buy Altera
From: Tim <tim@bugblat.invalid>
Date: Thu, 02 Apr 2015 00:36:04 +0100
Links: << >>  << T >>  << A >>
On 02/04/2015 00:10, rickman wrote:
> The part that gets me about the newer versions of this theme is that
> they are large, pricey FPGAs and incorporate fairly high end CPUs which
> are typically programmed under Linux...  a very far cry from the
> efficient solution I would like to see.  There are few engineers who can
> even design the entire system on that chip spanning logic design and
> system programming.
>

Is there any info on the price range for the latest Xilinx UltraScale+ 
parts?


Article: 157818
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Wed, 01 Apr 2015 19:52:26 -0400
Links: << >>  << T >>  << A >>
On 4/1/2015 7:27 PM, Rob Gaddi wrote:
> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>
>> On 4/1/2015 1:27 PM, John Speth wrote:
>
>>> I've used both example products with great success.  As you said, it's
>>> real convenient to roll your own peripherals with impunity.  It saved
>>> me hours of coding effort when you can smartly implement the peripheral
>>> of your dreams with a little HW design.
>>
>> The part that gets me about the newer versions of this theme is that
>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>> are typically programmed under Linux...  a very far cry from the
>> efficient solution I would like to see.  There are few engineers who can
>> even design the entire system on that chip spanning logic design and
>> system programming.
>
> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of
> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
> and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT
> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
> intention of running bare metal with 10-20K of code?  I'd take it in a
> heartbeat.

Learn Forth and make that 4 to 8 KB of code.  Which brings us to the 
possible reason they don't make the lower end CPUs in an FPGA... it 
competes against soft cores which can do the job you describe very well. 
  There are fast, efficient CPU cores which run at 100 MIPS and use 
under 1000 LUTs, not so much in your 10-20 kLUT device, eh?  Very 
probably cheaper in the long run than a chip with hard cores.

If you want to run bare-metal quick and easy, check out the J1 Forth CPU 
by James Bowman.  I've rolled my own similar CPUs and I really like his 
design.

http://www.excamera.com/sphinx/fpga-j1.html

Just as a point of comparison, the GA144 is a bit like an FPGA but uses 
tiny 18 bit processors as logic elements, 144 of them.  It pretty well 
sucks in many regards... well, "sucks" is a poor choice of words I 
guess.  But they had a cool idea of the tiny processors and connecting 
them in a net, but then totally forgot to consider any applications when 
designing a chip around it.

http://www.greenarraychips.com/home/products/

-- 

Rick

Article: 157819
Subject: Re: Intel in Talks to buy Altera
From: Richard Damon <Richard@Damon-Family.org>
Date: Wed, 01 Apr 2015 22:59:37 -0400
Links: << >>  << T >>  << A >>
On 4/1/15 7:27 PM, Rob Gaddi wrote:
> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>
>> On 4/1/2015 1:27 PM, John Speth wrote:
>
>>> I've used both example products with great success.  As you said, it's
>>> real convenient to roll your own peripherals with impunity.  It saved
>>> me hours of coding effort when you can smartly implement the peripheral
>>> of your dreams with a little HW design.
>>
>> The part that gets me about the newer versions of this theme is that
>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>> are typically programmed under Linux...  a very far cry from the
>> efficient solution I would like to see.  There are few engineers who can
>> even design the entire system on that chip spanning logic design and
>> system programming.
>
> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of
> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
> and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT
> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
> intention of running bare metal with 10-20K of code?  I'd take it in a
> heartbeat.
>

Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single 
M3, but that can often be enough.

Article: 157820
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Thu, 02 Apr 2015 02:06:21 -0400
Links: << >>  << T >>  << A >>
On 4/1/2015 10:59 PM, Richard Damon wrote:
> On 4/1/15 7:27 PM, Rob Gaddi wrote:
>> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>>
>>> On 4/1/2015 1:27 PM, John Speth wrote:
>>
>>>> I've used both example products with great success.  As you said, it's
>>>> real convenient to roll your own peripherals with impunity.  It saved
>>>> me hours of coding effort when you can smartly implement the peripheral
>>>> of your dreams with a little HW design.
>>>
>>> The part that gets me about the newer versions of this theme is that
>>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>>> are typically programmed under Linux...  a very far cry from the
>>> efficient solution I would like to see.  There are few engineers who can
>>> even design the entire system on that chip spanning logic design and
>>> system programming.
>>
>> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of
>> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
>> and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT
>> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
>> intention of running bare metal with 10-20K of code?  I'd take it in a
>> heartbeat.
>>
>
> Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single
> M3, but that can often be enough.

I had forgotten them.  In fact, I can't remember any of the details 
other than it using an M3 and having FPGA fabric.  This is a one time 
programmable part or a Flash part?

-- 

Rick

Article: 157821
Subject: Re: Intel in Talks to buy Altera
From: Richard Damon <Richard@Damon-Family.org>
Date: Thu, 02 Apr 2015 08:33:34 -0400
Links: << >>  << T >>  << A >>
On 4/2/15 2:06 AM, rickman wrote:
> On 4/1/2015 10:59 PM, Richard Damon wrote:
>> On 4/1/15 7:27 PM, Rob Gaddi wrote:
>>> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>>>
>>>> On 4/1/2015 1:27 PM, John Speth wrote:
>>>
>>>>> I've used both example products with great success.  As you said, it's
>>>>> real convenient to roll your own peripherals with impunity.  It saved
>>>>> me hours of coding effort when you can smartly implement the
>>>>> peripheral
>>>>> of your dreams with a little HW design.
>>>>
>>>> The part that gets me about the newer versions of this theme is that
>>>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>>>> are typically programmed under Linux...  a very far cry from the
>>>> efficient solution I would like to see.  There are few engineers who
>>>> can
>>>> even design the entire system on that chip spanning logic design and
>>>> system programming.
>>>
>>> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of
>>> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
>>> and etc.  Which, I mean we can make work.  But if I could get a
>>> 10-20KLUT
>>> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
>>> intention of running bare metal with 10-20K of code?  I'd take it in a
>>> heartbeat.
>>>
>>
>> Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single
>> M3, but that can often be enough.
>
> I had forgotten them.  In fact, I can't remember any of the details
> other than it using an M3 and having FPGA fabric.  This is a one time
> programmable part or a Flash part?
>

They are Flash based.

Article: 157822
Subject: Re: Intel in Talks to buy Altera
From: already5chosen@yahoo.com
Date: Thu, 2 Apr 2015 14:30:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>=20
> > On 4/1/2015 1:27 PM, John Speth wrote:
>=20
> >> I've used both example products with great success.  As you said, it's
> >> real convenient to roll your own peripherals with impunity.  It saved
> >> me hours of coding effort when you can smartly implement the periphera=
l
> >> of your dreams with a little HW design.
> >=20
> > The part that gets me about the newer versions of this theme is that
> > they are large, pricey FPGAs and incorporate fairly high end CPUs which
> > are typically programmed under Linux...  a very far cry from the
> > efficient solution I would like to see.  There are few engineers who ca=
n
> > even design the entire system on that chip spanning logic design and
> > system programming.
>=20
> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of=
=20
> which have big monster Cortex A9s meant to run Linux with a mess of DRAM=
=20
> and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT=
=20
> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every=20
> intention of running bare metal with 10-20K of code?  I'd take it in a=20
> heartbeat.
>=20
> --=20
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

Cortex-M is most useful when you have good chunk of flash on the same die. =
Which, unfortunately, would be incompatible with silicon tech used for mode=
rm FPGAs. DACs and SAR ADCs are also problem. Delta-sigma ADCs probably les=
s so, but I am not an expert. Anyway, for apps that I acre about SAR is mor=
e useful than delta-sigma.
Due to all these factors small embedded solution based on Cortex-M integrat=
ed into FPGA is likely to and up more complex, using more chips and more ex=
pensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

The ugly part about MCU + FPGA solution is that, unlike chips from the past=
, small modern Cortex-M MCUs rarely have good bus to talk to FPGA  (good=3D=
simple, not to slow and not too many pins). But then again, those old 32-bi=
t MCUs that had buses that I liked were in $25+ price range. For fair compa=
rison I probably have to look at old 8-bitter that I never even tried to co=
nnect to FPGA.

Back to another reason why I think that hard ARM Cortex-M4 core in [Altera =
or Xilinx] FPGA does not look as a very good proposition:
The added value of M3/M4 core alone, without flash and mixed-signal periphe=
rals, is not that big. After all Nios2-f core (only core, without debug sup=
port and avalon-mm infrastructure around it) occupies only ~25% of the smal=
lest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves compara=
ble performance. As far as I am concerned, the main advantage of Cortex-M i=
s a code density - significantly more code can fits on-chip. But even that =
is less important if were are talking about Cyclone5 generation, because he=
re the smallest member has 140 KB of embedded memory (not counting MLABs), =
which is often enough.

Article: 157823
Subject: Re: Intel in Talks to buy Altera
From: rickman <gnuarm@gmail.com>
Date: Thu, 02 Apr 2015 18:03:20 -0400
Links: << >>  << T >>  << A >>
On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:
> On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
>> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>>
>>> On 4/1/2015 1:27 PM, John Speth wrote:
>>
>>>> I've used both example products with great success.  As you said, it's
>>>> real convenient to roll your own peripherals with impunity.  It saved
>>>> me hours of coding effort when you can smartly implement the peripheral
>>>> of your dreams with a little HW design.
>>>
>>> The part that gets me about the newer versions of this theme is that
>>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>>> are typically programmed under Linux...  a very far cry from the
>>> efficient solution I would like to see.  There are few engineers who can
>>> even design the entire system on that chip spanning logic design and
>>> system programming.
>>
>> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both of
>> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
>> and etc.  Which, I mean we can make work.  But if I could get a 10-20KLUT
>> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
>> intention of running bare metal with 10-20K of code?  I'd take it in a
>> heartbeat.
>>
>> --
>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>> Email address domain is currently out of order.  See above to fix.
>
> Cortex-M is most useful when you have good chunk of flash on the same die. Which, unfortunately, would be incompatible with silicon tech used for moderm FPGAs.

That is a bit of nonsense unless you consider Lattice and MicroSemi to 
not be using "modern" FPGA processes.  They include Flash in their 
devices for the configuration memory.


> DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.

Once again you should tell that to MicroSemi... They make a mixed signal 
FPGA with CPU, analog and FPGA on one die.  I don't use it because of 
the price, a bit higher than I like to see.


> Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

I think you are saying that an FPGA with internal MCU is not as useful 
as separate FPGA and MCU because the MCU will have lots of other stuff 
integrated that would be additional chips with the integrated approach. 
  Clearly it doesn't have to be that ways since at least one company 
makes such parts.


> The ugly part about MCU + FPGA solution is that, unlike chips from the past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA  (good=simple, not to slow and not too many pins). But then again, those old 32-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA.

That brings us back to the real differences between the MCU world and 
the typical FPGA world.  MCUs are intended for apps where speed is 
limited by the software.  FPGAs are intended for apps where speed is 
potentially much faster with the limitation potentially in the I/O.  So 
a typical high end FPGA will have lots of I/O and some very fast I/O.

But such an integrated MCU/FPGA device would not be intended for high 
end apps with Mbps I/O.  The FPGA would be adding special functionality 
that perhaps can't be done in the MCU alone.  I had a design that 
required exactly this sort of need and ended up having to use an FPGA 
with an attached CODEC since there were no MCUs which could implement 
one interface.  The FPGA was a bit jammed up in terms of capacity (only 
3 kLUT).  A small soft core could do most of the work and potentially 
free up some space.  Had a combined chip been available it would have 
been a breeze to implement the one interface in hardware (or maybe two) 
and the rest of the design in software.


> Back to another reason why I think that hard ARM Cortex-M4 core in [Altera or Xilinx] FPGA does not look as a very good proposition:
> The added value of M3/M4 core alone, without flash and mixed-signal peripherals, is not that big. After all Nios2-f core (only core, without debug support and avalon-mm infrastructure around it) occupies only ~25% of the smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves comparable performance. As far as I am concerned, the main advantage of Cortex-M is a code density - significantly more code can fits on-chip. But even that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

Yep, the low end MCU on an FPGA without any of the peripherals would not 
be a lot more interesting than a soft core.  So when will they be doing 
a better job of the Vulcan mind meld and getting more analog on the FPGA 
die?  It's not like there is anything so special about FPGA logic that 
can't be done in analog compatible processes.  Maybe you lose some 
density or performance, but that isn't what we are after.  At least *I* 
am looking for a system on chip which includes some FPGA fabric.  Don't 
think of it as an FPGA with an MCU on chip.  Think of it as an MCU with 
FPGA fabric on chip just like the other umpty-nine peripherals they 
already have along with.... gasp!... 5 volt tolerance.  lol

-- 

Rick

Article: 157824
Subject: Re: Intel in Talks to buy Altera
From: already5chosen@yahoo.com
Date: Thu, 2 Apr 2015 15:52:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, April 3, 2015 at 1:03:23 AM UTC+3, rickman wrote:
> On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:
> > On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
> >> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
> >>
> >>> On 4/1/2015 1:27 PM, John Speth wrote:
> >>
> >>>> I've used both example products with great success.  As you said, it=
's
> >>>> real convenient to roll your own peripherals with impunity.  It save=
d
> >>>> me hours of coding effort when you can smartly implement the periphe=
ral
> >>>> of your dreams with a little HW design.
> >>>
> >>> The part that gets me about the newer versions of this theme is that
> >>> they are large, pricey FPGAs and incorporate fairly high end CPUs whi=
ch
> >>> are typically programmed under Linux...  a very far cry from the
> >>> efficient solution I would like to see.  There are few engineers who =
can
> >>> even design the entire system on that chip spanning logic design and
> >>> system programming.
> >>
> >> Agreed.  We're looking hard at both Zynq and the Cyclone V SOC, both o=
f
> >> which have big monster Cortex A9s meant to run Linux with a mess of DR=
AM
> >> and etc.  Which, I mean we can make work.  But if I could get a 10-20K=
LUT
> >> FPGA with a dual or quad Cortex M4 instead?  Nice and light with every
> >> intention of running bare metal with 10-20K of code?  I'd take it in a
> >> heartbeat.
> >>
> >> --
> >> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> >> Email address domain is currently out of order.  See above to fix.
> >
> > Cortex-M is most useful when you have good chunk of flash on the same d=
ie. Which, unfortunately, would be incompatible with silicon tech used for =
moderm FPGAs.
>=20
> That is a bit of nonsense unless you consider Lattice and MicroSemi to=20
> not be using "modern" FPGA processes.  They include Flash in their=20
> devices for the configuration memory.
>

Well, you are right, I am not familiar with Lattice and MicroSemi. From the=
 little I know about them their FPGA are modern in a sense that they a new =
products and, may be, modern in specific system-level features, but when it=
 comes to size and performance of the fabric, including such important to s=
ome of us characteristic as dynamic power per watt (static power is probabl=
y o.k) they are at least 5 years behind X&A, but probably more than 5.


>=20
> > DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, =
but I am not an expert. Anyway, for apps that I acre about SAR is more usef=
ul than delta-sigma.
>=20
> Once again you should tell that to MicroSemi... They make a mixed signal=
=20
> FPGA with CPU, analog and FPGA on one die.  I don't use it because of=20
> the price, a bit higher than I like to see.
>=20
>=20
> > Due to all these factors small embedded solution based on Cortex-M inte=
grated into FPGA is likely to and up more complex, using more chips and mor=
e expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.
>=20
> I think you are saying that an FPGA with internal MCU is not as useful=20
> as separate FPGA and MCU because the MCU will have lots of other stuff=20
> integrated that would be additional chips with the integrated approach.

Yes, NOR flash, ADCs, DACs.
=20
> Clearly it doesn't have to be that ways since at least one company=20
> makes such parts.
>=20
>=20
> > The ugly part about MCU + FPGA solution is that, unlike chips from the =
past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA  (goo=
d=3Dsimple, not to slow and not too many pins). But then again, those old 3=
2-bit MCUs that had buses that I liked were in $25+ price range. For fair c=
omparison I probably have to look at old 8-bitter that I never even tried t=
o connect to FPGA.
>=20
> That brings us back to the real differences between the MCU world and=20
> the typical FPGA world.  MCUs are intended for apps where speed is=20
> limited by the software.  FPGAs are intended for apps where speed is=20
> potentially much faster with the limitation potentially in the I/O.  So=
=20
> a typical high end FPGA will have lots of I/O and some very fast I/O.
>=20

That about right, except that I am not talking about high-end FPGAs, but ab=
out modern "low-cost" lines of A&X. So, fast I/O optional and very fast I/O=
 is rarely even an option (fast=3D1-3.125 Gbit/s, very fast=3D >3.125).
But for MCU<->FPGA interface I will be mostly satisfied in much more modera=
te speed. Say, something logically similar to venerable LPC bus, but withou=
t 24-bit address space limit (28 bits probably acceptable) and with physica=
l layer of RGMII.

> But such an integrated MCU/FPGA device would not be intended for high=20
> end apps with Mbps I/O.  The FPGA would be adding special functionality=
=20
> that perhaps can't be done in the MCU alone.  I had a design that=20
> required exactly this sort of need and ended up having to use an FPGA=20
> with an attached CODEC since there were no MCUs which could implement=20
> one interface.  The FPGA was a bit jammed up in terms of capacity (only=
=20
> 3 kLUT).  A small soft core could do most of the work and potentially=20
> free up some space.  Had a combined chip been available it would have=20
> been a breeze to implement the one interface in hardware (or maybe two)=
=20
> and the rest of the design in software.
>=20
>=20
> > Back to another reason why I think that hard ARM Cortex-M4 core in [Alt=
era or Xilinx] FPGA does not look as a very good proposition:
> > The added value of M3/M4 core alone, without flash and mixed-signal per=
ipherals, is not that big. After all Nios2-f core (only core, without debug=
 support and avalon-mm infrastructure around it) occupies only ~25% of the =
smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves com=
parable performance. As far as I am concerned, the main advantage of Cortex=
-M is a code density - significantly more code can fits on-chip. But even t=
hat is less important if were are talking about Cyclone5 generation, becaus=
e here the smallest member has 140 KB of embedded memory (not counting MLAB=
s), which is often enough.
>=20
> Yep, the low end MCU on an FPGA without any of the peripherals would not=
=20
> be a lot more interesting than a soft core.=20

Just a nitpick - by definition there is no such thing as "MCU without any o=
f the peripherals". Let's call them "MCU-style hard cores" or just "ARM Cor=
tex-M4" because this particular core looks like the most logical (or least =
illogical) candidate.

> So when will they be doing=20
> a better job of the Vulcan mind meld and getting more analog on the FPGA=
=20
> die?  It's not like there is anything so special about FPGA logic that=20
> can't be done in analog compatible processes.  Maybe you lose some=20
> density or performance, but that isn't what we are after.  At least *I*=
=20
> am looking for a system on chip which includes some FPGA fabric.  Don't=
=20
> think of it as an FPGA with an MCU on chip.=20

Yes, could be nice. But to be real useful FPGA part should not be too small=
. I wouldn't bother for 1K 4-input LUTs. 5K looks like reasonable minimum, =
at least for gray haired devs like you and me. Younger guys a spoiled, they=
'd want more than that.

> Think of it as an MCU with=20
> FPGA fabric on chip just like the other umpty-nine peripherals they=20
> already have along with.... gasp!... 5 volt tolerance.  lol
>

Is 5-V tolerance really that useful [in new designs] without ability to act=
ually drive 5V outputs? I suppose, even you don't expect the later in 2015 =
:-)

> --=20
>=20
> Rick




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
2019JanFebMar2019

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