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 159375

Article: 159375
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Oct 2016 19:01:22 -0400
Links: << >>  << T >>  << A >>
On 10/17/2016 12:15 PM, John Larkin wrote:
> On Sun, 16 Oct 2016 19:55:13 -0500, Tim Wescott
> <tim@seemywebsite.really> wrote:
>
>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman wrote:
>>
>>> I found this pretty impressive.  I wonder if this is why Intel bought
>>> Altera or if they are not working together on this?  Ulpp!  Seak and yea
>>> shall find....
>>>
>>> "Microsoft is using so many FPGA the company has a direct influence over
>>> the global FPGA supply and demand. Intel executive vice president, Diane
>>> Bryant, has already stated that Microsoft is the main reason behind
>>> Intel's decision to acquire FPGA-maker, Altera."
>>>
>>> #Microsoft's #FPGA Translates #Wikipedia in less than a Tenth of a
>>> Second http://hubs.ly/H04JLSp0
>>>
>>> I guess this will only steer the FPGA market more in the direction of
>>> larger and faster rather than giving us much at the low end of energy
>>> efficient and small FPGAs.  That's where I like to live.
>>
>> Hopefully it'll create a vacuum into which other companies will grow.
>> Very possibly not without some pain in the interim.  Markets change, we
>> have to adapt.
>
> The interim pain includes an almost total absence of tech support for
> the smaller users. The biggies get a team of full-time, on-site
> support people; small users can't get any support from the principals,
> and maybe a little mediocre support from distributors.
>
> That trend is almost universal, but it's worst with FPGAs, where the
> tools are enormously complex and correspondingly buggy. Got a problem?
> Post it on a forum.

The tools for the Zynq is complex.  For the most part the FPGA tools are 
fine and not any more problematic than tools for CPUs.  Its the funky 
interface stuff inside the Zynq that makes it complex.  Its new so the 
tools aren't polished.  Bottom line is they aren't going to spend some 
kilo bucks to support a sub thousand part user when they have mega part 
users they need to support.  That's pretty universal, not just FPGAs.

-- 

Rick C

Article: 159376
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a Second
From: krw <krw@nowhere.com>
Date: Mon, 17 Oct 2016 21:13:46 -0400
Links: << >>  << T >>  << A >>
On Mon, 17 Oct 2016 03:56:46 -0400, rickman <gnuarm@gmail.com> wrote:

>On 10/16/2016 8:55 PM, Tim Wescott wrote:
>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman wrote:
>>
>>> I found this pretty impressive.  I wonder if this is why Intel bought
>>> Altera or if they are not working together on this?  Ulpp!  Seak and yea
>>> shall find....
>>>
>>> "Microsoft is using so many FPGA the company has a direct influence over
>>> the global FPGA supply and demand. Intel executive vice president, Diane
>>> Bryant, has already stated that Microsoft is the main reason behind
>>> Intel's decision to acquire FPGA-maker, Altera."
>>>
>>> #Microsoft's #FPGA Translates #Wikipedia in less than a Tenth of a
>>> Second http://hubs.ly/H04JLSp0
>>>
>>> I guess this will only steer the FPGA market more in the direction of
>>> larger and faster rather than giving us much at the low end of energy
>>> efficient and small FPGAs.  That's where I like to live.
>>
>> Hopefully it'll create a vacuum into which other companies will grow.
>> Very possibly not without some pain in the interim.  Markets change, we
>> have to adapt.
>
>I've never been clear on the fundamental forces in the FPGA business. 
>The major FPGA companies have operated very similarly catering to the 
>telecom markets while giving pretty much lip service to the rest of the 
>electronics world.

Lattice has some pretty nice low-end parts.  Altera did, too, but
that'll probably change.
>
>I suppose there is a difference in technology requirements between MCUs 
>and FPGAs.  MCUs often are not even near the bleeding edge of process 
>technology while FPGAs seem to drive it to some extent.  Other than 
>Intel who seems to always be the first to bring chips out at a given 
>process node, the FPGA companies are a close second.  But again, I think 
>that is driven by their serving the telecom market where density is king.

MCUs have a huge development cost/cycle.  FPGAs are arrays of the same
thing.  Being arrays, they're easier to debug/test, as well.  Telecom
and defense.
>
>So I don't see any fundamental reasons why FPGAs can't be built on older 
>processes to keep price down.  If MCUs can be made in a million 
>combinations of RAM, Flash and peripherals, why can't FPGAs?  Even 
>analog is used in MCUs, why can't FPGAs be made with the same processes 
>giving us programmable logic combined with a variety of ADC, DAC and 
>comparators on the same die.  Put them in smaller packages (lower pin 
>counts, not the micro pitch BGAs) and let them to be used like MCUs.

The different MCU combinations are often the same chips with
fuse-blows for the different configurations, not that this couldn't be
(or isn't) done with FPGAs, as well.
>
>Maybe the market just isn't there.  Many seem to feel FPGAs are much 
>harder to work with than MCUs.  To me they are much simpler.

Article: 159377
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Oct 2016 02:06:31 -0400
Links: << >>  << T >>  << A >>
On 10/17/2016 9:13 PM, krw wrote:
> On Mon, 17 Oct 2016 03:56:46 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> On 10/16/2016 8:55 PM, Tim Wescott wrote:
>>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman wrote:
>>>
>>>> I found this pretty impressive.  I wonder if this is why Intel bought
>>>> Altera or if they are not working together on this?  Ulpp!  Seak and yea
>>>> shall find....
>>>>
>>>> "Microsoft is using so many FPGA the company has a direct influence over
>>>> the global FPGA supply and demand. Intel executive vice president, Diane
>>>> Bryant, has already stated that Microsoft is the main reason behind
>>>> Intel's decision to acquire FPGA-maker, Altera."
>>>>
>>>> #Microsoft's #FPGA Translates #Wikipedia in less than a Tenth of a
>>>> Second http://hubs.ly/H04JLSp0
>>>>
>>>> I guess this will only steer the FPGA market more in the direction of
>>>> larger and faster rather than giving us much at the low end of energy
>>>> efficient and small FPGAs.  That's where I like to live.
>>>
>>> Hopefully it'll create a vacuum into which other companies will grow.
>>> Very possibly not without some pain in the interim.  Markets change, we
>>> have to adapt.
>>
>> I've never been clear on the fundamental forces in the FPGA business.
>> The major FPGA companies have operated very similarly catering to the
>> telecom markets while giving pretty much lip service to the rest of the
>> electronics world.
>
> Lattice has some pretty nice low-end parts.  Altera did, too, but
> that'll probably change.
>>
>> I suppose there is a difference in technology requirements between MCUs
>> and FPGAs.  MCUs often are not even near the bleeding edge of process
>> technology while FPGAs seem to drive it to some extent.  Other than
>> Intel who seems to always be the first to bring chips out at a given
>> process node, the FPGA companies are a close second.  But again, I think
>> that is driven by their serving the telecom market where density is king.
>
> MCUs have a huge development cost/cycle.  FPGAs are arrays of the same
> thing.  Being arrays, they're easier to debug/test, as well.  Telecom
> and defense.
>>
>> So I don't see any fundamental reasons why FPGAs can't be built on older
>> processes to keep price down.  If MCUs can be made in a million
>> combinations of RAM, Flash and peripherals, why can't FPGAs?  Even
>> analog is used in MCUs, why can't FPGAs be made with the same processes
>> giving us programmable logic combined with a variety of ADC, DAC and
>> comparators on the same die.  Put them in smaller packages (lower pin
>> counts, not the micro pitch BGAs) and let them to be used like MCUs.
>
> The different MCU combinations are often the same chips with
> fuse-blows for the different configurations, not that this couldn't be
> (or isn't) done with FPGAs, as well.

It definitely is done with FPGAs.  I make a board with a Lattice part 
that is EOL.  The part is a 3.3 volt only version, but I had added a 
voltage regulator so the 1.2 volt core version can be used.  With this 
last batch of boards the 1.2 volt version was much cheaper than the 3.3 
volt version.  But I didn't want to have to run the tools to produce a 
new bit file.  The FAE said he thought they might use the same die and 
so would have the same bit stream most likely.  I found what I had to 
change in the tools to get it to let me download the old version of the 
bit stream into the 1.2 volt device and it worked.  So clearly the die 
is the same.  There is a just bonding difference that bypasses the 1.2 
volt internal regulator.

-- 

Rick C

Article: 159378
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 18 Oct 2016 10:35:00 +0200
Links: << >>  << T >>  << A >>
On 18/10/16 00:45, rickman wrote:
> On 10/17/2016 6:25 AM, David Brown wrote:
>> On 17/10/16 09:56, rickman wrote:
>>> On 10/16/2016 8:55 PM, Tim Wescott wrote:
>>>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman wrote:
>>>>
>>>>> I found this pretty impressive.  I wonder if this is why Intel bought
>>>>> Altera or if they are not working together on this?  Ulpp!  Seak
>>>>> and yea
>>>>> shall find....
>>>>>
>>>>> "Microsoft is using so many FPGA the company has a direct influence
>>>>> over
>>>>> the global FPGA supply and demand. Intel executive vice president,
>>>>> Diane
>>>>> Bryant, has already stated that Microsoft is the main reason behind
>>>>> Intel's decision to acquire FPGA-maker, Altera."
>>>>>
>>>>> #Microsoft's #FPGA Translates #Wikipedia in less than a Tenth of a
>>>>> Second http://hubs.ly/H04JLSp0
>>>>>
>>>>> I guess this will only steer the FPGA market more in the direction of
>>>>> larger and faster rather than giving us much at the low end of energy
>>>>> efficient and small FPGAs.  That's where I like to live.
>>>>
>>>> Hopefully it'll create a vacuum into which other companies will grow.
>>>> Very possibly not without some pain in the interim.  Markets change, we
>>>> have to adapt.
>>>
>>> I've never been clear on the fundamental forces in the FPGA business.
>>> The major FPGA companies have operated very similarly catering to the
>>> telecom markets while giving pretty much lip service to the rest of the
>>> electronics world.
>>>
>>> I suppose there is a difference in technology requirements between MCUs
>>> and FPGAs.  MCUs often are not even near the bleeding edge of process
>>> technology while FPGAs seem to drive it to some extent.  Other than
>>> Intel who seems to always be the first to bring chips out at a given
>>> process node, the FPGA companies are a close second.  But again, I think
>>> that is driven by their serving the telecom market where density is
>>> king.
>>>
>>> So I don't see any fundamental reasons why FPGAs can't be built on older
>>> processes to keep price down.  If MCUs can be made in a million
>>> combinations of RAM, Flash and peripherals, why can't FPGAs?  Even
>>> analog is used in MCUs, why can't FPGAs be made with the same processes
>>> giving us programmable logic combined with a variety of ADC, DAC and
>>> comparators on the same die.  Put them in smaller packages (lower pin
>>> counts, not the micro pitch BGAs) and let them to be used like MCUs.
>>
>> As far as I understand it, there is quite a variation in the types of
>> processes used - it's not just about the feature size.  The number of
>> layers, the types of layers, the types of doping, the fault tolerance,
>> etc., all play a part in what fits well on the same die.  So you might
>> easily find that if you put an ADC on a die setup that was good for FPGA
>> fabric, then the ADC would be a lot worse (speed, accuracy, power
>> consumption, noise, cost) than usual.  Alternatively, your die setup
>> could be good for the ADC - and then it would give a poor quality FPGA
>> part.
> 
> What's a "poor" FPGA?

What is a "good" FPGA?  It has fast switching, predictable timing, low
power, low cost, lots of gates, registers and memory, flexible routing,
etc.  A "poor" FPGA is one that is significantly worse in some or all of
these features than you might otherwise expect.

> MCUs have digital and usually as fast as possible
> digital.  They also want the lowest possible power consumption.  What
> part of that is bad for an FPGA?

The digital parts of an MCU are fixed.  Each gate in an MCU design is a
tiny fraction of the size, cost, power and latency of a logic element in
an FPGA.  Just compare the speed, die size and power of a hard cpu macro
in an FPGA with a soft cpu on the same device - the hard macro is hugely
superior in every way except flexibility.

Now, I don't have any good references for what I am writing here - just
"things I have read" and "things I know about".  So if you or anyone
else knows better, I am happy to be corrected - and if any of this is
important to you (rather than just for interest), please check it with
more knowledgeable people.  With that disclaimer,...

There are important differences between the die stackup for FPGA design
and other types of digital logic.  The most obvious feature is that for
high-end FPGA's, there are many more layers in the die than you usually
get for microcontrollers or even fast cpus.  FPGA's need a /lot/ more
routing lines than fixed digital parts.  These routes are mostly highly
symmetrical, and can be tightly packed because only a small fraction of
them are ever active in any given design - you don't need enough power
or heat dissipation for them all.  On a microcontroller or other digital
part, you have far more complex routing patterns, with most routes being
short distance and you can have most of them active at a time.  On
memory parts, you have a different type of routing pattern again - few
layers, with a lot of symmetry, and a lot of simultaneous switching on
some of the buses.

The point is, the optimal die stackup and process technology for an FPGA
is different from the optimal setup for an MCU, a memory block, analogue
blocks, etc.  So when you combine these, you are making a lot of
compromises.

It is relatively easy and cost-effective to take a big, expensive FPGA
die design and stick a little processor on it somewhere.  You can spread
the normal cpu routing amongst the many FPGA routing layers for better
power and heat spreading.  It will be a little bigger and slower than a
dedicated cpu die could be, and the cost per mm² is higher - but that
extra cost is small in the total cost of the chip.

But you cannot take an optimised microcontroller or cpu die design and
add serious FPGA hardware to it - you simply don't have the routing
space.  You can add some CPLD-type programmable logic without too much
extra cost (look at the AVR XMega E series, or the PSoC devices) because
that kind of programmable logic puts more weight on complex logic blocks
and less on the routing.


Note that flash is also a poor fit for both MCU and FPGA die stacks.
For flash, you want a different kind of transistor than for the purely
digital parts, you have significant analogue areas, and you need to deal
with high voltages and a charge pump.  The match between an MCU and
flash is not too bad - so the combination of the two parts on the same
die is clearly a "win" overall.  But if you want the best (cheapest,
fastest, highest density, lowest power) flash block, you don't mix it
with a cpu on the same die - similarly if you want the best cpu block.
As far as I know (and as noted above, I may be wrong), Flash FPGA
devices are made with a large FPGA die and a small serial flash die
packaged together.


You get the same for analogue parts.  You can buy devices that are good
microcontrollers with okay analogue parts built in.  You can buy devices
that are basically high-end analogue parts with a half-decent
microcontroller tagged on.  But you /cannot/ buy a device that has
high-end analogue interfaces /and/ a high-end processor or
microcontroller, all on the same die.


It is just like PCB design.  You do not easily match 1000V IGBT
switchers, 1000-pin 0.4mm pitch BGAs, and 24-bit ADCs on the same board.


>  Forget the analog.  What do you
> sacrifice by building FPGAs on a line that works well for CPUs with
> Flash and RAM?  If you can also build decent analog with that you get an
> MCU/FPGA/Analog device that is no worse than current MCUs.
> 
> 
>> Microcontrollers are made with a compromise.  The cpu part is not as
>> fast or efficient as a pure cpu could be, nor is the flash part, nor the
>> analogue parts.  But they are all good enough that the combination is a
>> saving (in dollars and watts, as well as mm²) overall.
> 
> It's not much of a compromise.  As you say, they are all good enough.  I
> am sure an FPGA could be combined with little loss of what defines an FPGA.
> 

As I wrote above, the compromise is significant.  It is certainly worth
making in some cases - and I too would like to see such combined
devices.  And I think we will see such devices turning up - technology
progress will reduce the technical disadvantages, and economy of scale
will reduce the cost disadvantages.  But it is not as simple a matter as
you might think.

And then, of course, there is the joys of making tools that let
developers work easily with the whole system - that is not a small matter.

I believe that what we will see first is something more like the
above-mentioned Atmel XMega E series, or some of the PIC devices
(AFAIK), where you have a "normal" microcontroller with a bit of
programmable logic.  This will give designers a good deal more
flexibility in their layouts.  Rather than buying a part with 3 UARTs
and 2 SPI where one of the SPI's shares the pins of one of the UARTs,
the developer could use the chip's pin switch matrix to get all 5
interfaces at once.  Some simple PLD blocks could give you high-speed
interfaces without external glue logic, and they could let the chip
support a wide range of timer functions without the chip designer having
to think of every desirable combination in advance.

> 
>> But I think there are some FPGA's with basic analogue parts, and
>> certainly with flash.  There are also microcontrollers with some
>> programmable logic (more CPLD-type logic than FPGA).  Maybe we will see
>> more "compromise" parts in the future, but I doubt if we will see good
>> analogue bits and good FPGA bits on the same die.
> 
> I know of one (well one line) from Microsemi (formerly Actel),
> SmartFusion (not to be confused with SmartFusion2).  They have a CM3
> with SAR ADC and sigma-delta DAC, comparators, etc in addition to the
> FPGA.  So clearly this is possible and it is really a marketing issue,
> not a technical one.

No, it is a combination of many issues and compromises.  When Actel saw
the success of SmartFusion and thought how they could make a new
SmartFusion2 family, they did not think "no one really wants analogue
interfaces, so we can remove that" - they made the sacrifices needed to
get the other features they needed.  It was very much a compromise.

But you are right that the SmartFusion shows that combinations can be
made - just as the SmartFusion2 shows that it is not a simple matter.

> 
> The focus seems to be on the FPGA

Indeed.  And that is how it (currently, at least) must be if you want
decent FPGA on the device.

>, but they do give a decent amount of
> Flash and RAM (up to 512 and 64 kB respectively).  My main issue is the
> very large packages, all BGA except for the ginormous TQ144.  I'd like
> to see 64 and 100 pin QFPs.

The packaging is something that should be easier to change - there is no
technical reason not to put the same chip in a lower pin package (as
long as the package is big enough for the die and a carrier pcb, of course).

> 
> 
>> What will, I think, make more of a difference is multi-die packaging -
>> either as side-by-side dies or horizontally layered dies.  But I expect
>> that to be more on the high-end first (like FPGA die combined with big
>> ram blocks).
> 
> Very pointless not to mention costly.  You lose a lot running the FPGA
> to MCU interface through I/O pads for some applications.  That is how
> Intel combined FPGA with their x86 CPUs initially though.  But it is a
> very pricey result.


No, it is certainly not pointless - although it certainly /is/ costly at
the moment.  Horizontal side-by-side packaging is an established
technique, and is used in a number of high-end devices.  If you have a
wide and fast memory bus, then the whole thing can be much smaller,
simpler and lower power if the dies are adjacent and you have short,
thin traces between dies on a carrier pcb within the package.  The board
designer has no issues with length or impedance matching, and the line
drivers are far smaller and lower power.

Vertical die-on-die stacking is a newer technology, with a good deal of
research into a variety of techniques.  It is already in use for
symmetrical designs such as multi-die DRAM and Flash packages.  But the
real benefit will come with DRAM dies connected to processor or FPGA
dies.  Rather than having a 64-bit wide databus with powerful
bi-directional drivers, complex serialisation/deserialisation hardware,
PLL's, etc., a 20-bit address/command bus with tracking of pages,
pre-fetches, etc., you could just have a full-duplex 512-bit wide
databus and full address bus, with everything running at a lower clock
rate and data lines driven over a distance of a mm or two.  Total system
power would be cut drastically, as would latency, and you could drop
much of the complex interface and control circuitry on both sides of the
link.  Your DRAM starts to look more like wide tightly-coupled SRAM -
your processor can drop all but its L0 cache.

There are still many manufacturing challenges to overcome, and heat
management is hard, but it will come - the potential benefits are enormous.

> 
> 
>>> Maybe the market just isn't there.  Many seem to feel FPGAs are much
>>> harder to work with than MCUs.  To me they are much simpler.
>>>
>>
>> I think that is habit and familiarity - there is a lot of difference to
>> the mindset for FPGA programming and MCU programming.  I don't think you
>> can say that one type of development is fundamentally harder or easier
>> than the other, but the simple fact is that a great deal more people are
>> familiar with programming serial execution devices than with developing
>> for programmable logic.
> 
> The main difference between programming MCUs and FPGAs is you don't need
> to be concerned with the problems of virtual multitasking (sharing one
> processor between many tasks).  Otherwise FPGAs are pretty durn simple
> to use really.  For sure, some tasks fit well in an MCU.  If you have
> the performance they can be done in an MCU, but that is not a reason why
> they can't be done in an FPGA just as easily.  I know, many times I've
> taken an MCU algorithm and coded it into HDL.  The hard part is
> understanding what the MCU code is doing.
> 



Article: 159379
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Oct 2016 05:05:15 -0400
Links: << >>  << T >>  << A >>
On 10/18/2016 4:35 AM, David Brown wrote:
> On 18/10/16 00:45, rickman wrote:
>> On 10/17/2016 6:25 AM, David Brown wrote:
>>> On 17/10/16 09:56, rickman wrote:
>>>> On 10/16/2016 8:55 PM, Tim Wescott wrote:
>>>>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman wrote:
>>>>>
>>>>>> I found this pretty impressive.  I wonder if this is why Intel bought
>>>>>> Altera or if they are not working together on this?  Ulpp!  Seak
>>>>>> and yea
>>>>>> shall find....
>>>>>>
>>>>>> "Microsoft is using so many FPGA the company has a direct influence
>>>>>> over
>>>>>> the global FPGA supply and demand. Intel executive vice president,
>>>>>> Diane
>>>>>> Bryant, has already stated that Microsoft is the main reason behind
>>>>>> Intel's decision to acquire FPGA-maker, Altera."
>>>>>>
>>>>>> #Microsoft's #FPGA Translates #Wikipedia in less than a Tenth of a
>>>>>> Second http://hubs.ly/H04JLSp0
>>>>>>
>>>>>> I guess this will only steer the FPGA market more in the direction of
>>>>>> larger and faster rather than giving us much at the low end of energy
>>>>>> efficient and small FPGAs.  That's where I like to live.
>>>>>
>>>>> Hopefully it'll create a vacuum into which other companies will grow.
>>>>> Very possibly not without some pain in the interim.  Markets change, we
>>>>> have to adapt.
>>>>
>>>> I've never been clear on the fundamental forces in the FPGA business.
>>>> The major FPGA companies have operated very similarly catering to the
>>>> telecom markets while giving pretty much lip service to the rest of the
>>>> electronics world.
>>>>
>>>> I suppose there is a difference in technology requirements between MCUs
>>>> and FPGAs.  MCUs often are not even near the bleeding edge of process
>>>> technology while FPGAs seem to drive it to some extent.  Other than
>>>> Intel who seems to always be the first to bring chips out at a given
>>>> process node, the FPGA companies are a close second.  But again, I think
>>>> that is driven by their serving the telecom market where density is
>>>> king.
>>>>
>>>> So I don't see any fundamental reasons why FPGAs can't be built on older
>>>> processes to keep price down.  If MCUs can be made in a million
>>>> combinations of RAM, Flash and peripherals, why can't FPGAs?  Even
>>>> analog is used in MCUs, why can't FPGAs be made with the same processes
>>>> giving us programmable logic combined with a variety of ADC, DAC and
>>>> comparators on the same die.  Put them in smaller packages (lower pin
>>>> counts, not the micro pitch BGAs) and let them to be used like MCUs.
>>>
>>> As far as I understand it, there is quite a variation in the types of
>>> processes used - it's not just about the feature size.  The number of
>>> layers, the types of layers, the types of doping, the fault tolerance,
>>> etc., all play a part in what fits well on the same die.  So you might
>>> easily find that if you put an ADC on a die setup that was good for FPGA
>>> fabric, then the ADC would be a lot worse (speed, accuracy, power
>>> consumption, noise, cost) than usual.  Alternatively, your die setup
>>> could be good for the ADC - and then it would give a poor quality FPGA
>>> part.
>>
>> What's a "poor" FPGA?
>
> What is a "good" FPGA?  It has fast switching, predictable timing, low
> power, low cost, lots of gates, registers and memory, flexible routing,
> etc.  A "poor" FPGA is one that is significantly worse in some or all of
> these features than you might otherwise expect.

So which of these go to hell when you use a process in use by MCU 
makers?  Heck, you mention Flash putting the clock back a couple of 
process nodes, but that is what I am using, Lattice Flash FPGAs.


>> MCUs have digital and usually as fast as possible
>> digital.  They also want the lowest possible power consumption.  What
>> part of that is bad for an FPGA?
>
> The digital parts of an MCU are fixed.  Each gate in an MCU design is a
> tiny fraction of the size, cost, power and latency of a logic element in
> an FPGA.  Just compare the speed, die size and power of a hard cpu macro
> in an FPGA with a soft cpu on the same device - the hard macro is hugely
> superior in every way except flexibility.

None of that is relevant.  The point is the process used for MCUs with 
Flash, RAM and analog is just as good for FPGAs if you aren't trying to 
be on the bleeding edge.


> Now, I don't have any good references for what I am writing here - just
> "things I have read" and "things I know about".  So if you or anyone
> else knows better, I am happy to be corrected - and if any of this is
> important to you (rather than just for interest), please check it with
> more knowledgeable people.  With that disclaimer,...
>
> There are important differences between the die stackup for FPGA design
> and other types of digital logic.  The most obvious feature is that for
> high-end FPGA's, there are many more layers in the die than you usually
> get for microcontrollers or even fast cpus.  FPGA's need a /lot/ more
> routing lines than fixed digital parts.  These routes are mostly highly
> symmetrical, and can be tightly packed because only a small fraction of
> them are ever active in any given design - you don't need enough power
> or heat dissipation for them all.  On a microcontroller or other digital
> part, you have far more complex routing patterns, with most routes being
> short distance and you can have most of them active at a time.  On
> memory parts, you have a different type of routing pattern again - few
> layers, with a lot of symmetry, and a lot of simultaneous switching on
> some of the buses.

You said the key words... "high-end FPGA's" [sic].  I'm not talking 
about high end FPGAs.  I'm talking about small parts at the low end 
combined with an MCU and analog.  Even the Xilinx Zynq parts use very 
fast, very power hungry CPUs that require off chip memory.  Totally 
different market... as usual, the telecom market.


> The point is, the optimal die stackup and process technology for an FPGA
> is different from the optimal setup for an MCU, a memory block, analogue
> blocks, etc.  So when you combine these, you are making a lot of
> compromises.

Compromises, yes, "lot of"...  I don't know.  That's my point.  They 
make those compromises for MCUs and seem to make it work.  You have said 
nothing about why a useful FPGA can't be made using the same process as 
an MCU.  You just talk about what they do when trying to squeeze every 
bit out of the silicon for the express purpose of large, fast FPGAs. 
Not every design needs large or fast.


> It is relatively easy and cost-effective to take a big, expensive FPGA
> die design and stick a little processor on it somewhere.  You can spread
> the normal cpu routing amongst the many FPGA routing layers for better
> power and heat spreading.  It will be a little bigger and slower than a
> dedicated cpu die could be, and the cost per mm² is higher - but that
> extra cost is small in the total cost of the chip.
>
> But you cannot take an optimised microcontroller or cpu die design and
> add serious FPGA hardware to it - you simply don't have the routing
> space.  You can add some CPLD-type programmable logic without too much
> extra cost (look at the AVR XMega E series, or the PSoC devices) because
> that kind of programmable logic puts more weight on complex logic blocks
> and less on the routing.

This does not make sense at all.  First, most CPLD type devices are 
actually FPGA type devices in a smaller capacity.  Second, and FPGA uses 
die space.  There is nothing magical about how much space is needed for 
routing or anything else.  Just add a block of FPGA fabric to an MCU 
with an appropriate special interface and Bob's your uncle.  The proof 
of the pudding is the fact that it has been done.  My question is why 
this isn't done more often with a wider variety of parts, in particular 
more vendors.


> Note that flash is also a poor fit for both MCU and FPGA die stacks.
> For flash, you want a different kind of transistor than for the purely
> digital parts, you have significant analogue areas, and you need to deal
> with high voltages and a charge pump.  The match between an MCU and
> flash is not too bad - so the combination of the two parts on the same
> die is clearly a "win" overall.  But if you want the best (cheapest,
> fastest, highest density, lowest power) flash block, you don't mix it
> with a cpu on the same die - similarly if you want the best cpu block.
> As far as I know (and as noted above, I may be wrong), Flash FPGA
> devices are made with a large FPGA die and a small serial flash die
> packaged together.

Yes, none of these things want to be on the same die, and yet it 
happens.  You are mistaken about the Flash FPGAs.  Only Xilinx adds a 
flash chip to an FPGA chip in one package.  That offers little 
advantage.  The Lattice parts have the flash on the die and offer *much* 
faster configuration load times, on the order of 1 ms instead of 100s of 
ms.


> You get the same for analogue parts.  You can buy devices that are good
> microcontrollers with okay analogue parts built in.  You can buy devices
> that are basically high-end analogue parts with a half-decent
> microcontroller tagged on.  But you /cannot/ buy a device that has
> high-end analogue interfaces /and/ a high-end processor or
> microcontroller, all on the same die.

So?


> It is just like PCB design.  You do not easily match 1000V IGBT
> switchers, 1000-pin 0.4mm pitch BGAs, and 24-bit ADCs on the same board.
>
>
>>  Forget the analog.  What do you
>> sacrifice by building FPGAs on a line that works well for CPUs with
>> Flash and RAM?  If you can also build decent analog with that you get an
>> MCU/FPGA/Analog device that is no worse than current MCUs.
>>
>>
>>> Microcontrollers are made with a compromise.  The cpu part is not as
>>> fast or efficient as a pure cpu could be, nor is the flash part, nor the
>>> analogue parts.  But they are all good enough that the combination is a
>>> saving (in dollars and watts, as well as mm²) overall.
>>
>> It's not much of a compromise.  As you say, they are all good enough.  I
>> am sure an FPGA could be combined with little loss of what defines an FPGA.
>>
>
> As I wrote above, the compromise is significant.  It is certainly worth
> making in some cases - and I too would like to see such combined
> devices.  And I think we will see such devices turning up - technology
> progress will reduce the technical disadvantages, and economy of scale
> will reduce the cost disadvantages.  But it is not as simple a matter as
> you might think.

I don't know where you get the "significant" part.  They sell literally 
billions of MCUs with analog on them each year.  Obviously the 
compromise is not so bad.


> And then, of course, there is the joys of making tools that let
> developers work easily with the whole system - that is not a small matter.

Only if you try to make it complex and ugly.  Interfacing an FPGA to a 
CPU is not hard.


> I believe that what we will see first is something more like the
> above-mentioned Atmel XMega E series, or some of the PIC devices
> (AFAIK), where you have a "normal" microcontroller with a bit of
> programmable logic.  This will give designers a good deal more
> flexibility in their layouts.  Rather than buying a part with 3 UARTs
> and 2 SPI where one of the SPI's shares the pins of one of the UARTs,
> the developer could use the chip's pin switch matrix to get all 5
> interfaces at once.  Some simple PLD blocks could give you high-speed
> interfaces without external glue logic, and they could let the chip
> support a wide range of timer functions without the chip designer having
> to think of every desirable combination in advance.

You mean you have seen these before Microsemi (formerly Atmel) came out 
with their SmartFusion and SmartFusion2 devices?


>>> But I think there are some FPGA's with basic analogue parts, and
>>> certainly with flash.  There are also microcontrollers with some
>>> programmable logic (more CPLD-type logic than FPGA).  Maybe we will see
>>> more "compromise" parts in the future, but I doubt if we will see good
>>> analogue bits and good FPGA bits on the same die.
>>
>> I know of one (well one line) from Microsemi (formerly Actel),
>> SmartFusion (not to be confused with SmartFusion2).  They have a CM3
>> with SAR ADC and sigma-delta DAC, comparators, etc in addition to the
>> FPGA.  So clearly this is possible and it is really a marketing issue,
>> not a technical one.
>
> No, it is a combination of many issues and compromises.  When Actel saw
> the success of SmartFusion and thought how they could make a new
> SmartFusion2 family, they did not think "no one really wants analogue
> interfaces, so we can remove that" - they made the sacrifices needed to
> get the other features they needed.  It was very much a compromise.

What other features?  Engineering doesn't dictate products.  Marketing 
does.  Clearly Microsemi feels there is not enough of a market to 
provide the "everything" chip.   I've had this discussion with Xilinx 
and they don't say it is too hard to do.  They say it makes the number 
of different line items they have to inventory far too large.  That's 
not an engineering problem.  That is exactly what they do with MCUS, 
dozens or even hundreds of different versions.  It just needs to be what 
your company wants to do... as decided by marketing.


> But you are right that the SmartFusion shows that combinations can be
> made - just as the SmartFusion2 shows that it is not a simple matter.
>
>>
>> The focus seems to be on the FPGA
>
> Indeed.  And that is how it (currently, at least) must be if you want
> decent FPGA on the device.
>
>> , but they do give a decent amount of
>> Flash and RAM (up to 512 and 64 kB respectively).  My main issue is the
>> very large packages, all BGA except for the ginormous TQ144.  I'd like
>> to see 64 and 100 pin QFPs.
>
> The packaging is something that should be easier to change - there is no
> technical reason not to put the same chip in a lower pin package (as
> long as the package is big enough for the die and a carrier pcb, of course).
>
>>
>>
>>> What will, I think, make more of a difference is multi-die packaging -
>>> either as side-by-side dies or horizontally layered dies.  But I expect
>>> that to be more on the high-end first (like FPGA die combined with big
>>> ram blocks).
>>
>> Very pointless not to mention costly.  You lose a lot running the FPGA
>> to MCU interface through I/O pads for some applications.  That is how
>> Intel combined FPGA with their x86 CPUs initially though.  But it is a
>> very pricey result.
>
>
> No, it is certainly not pointless - although it certainly /is/ costly at
> the moment.  Horizontal side-by-side packaging is an established
> technique, and is used in a number of high-end devices.  If you have a
> wide and fast memory bus, then the whole thing can be much smaller,
> simpler and lower power if the dies are adjacent and you have short,
> thin traces between dies on a carrier pcb within the package.  The board
> designer has no issues with length or impedance matching, and the line
> drivers are far smaller and lower power.
>
> Vertical die-on-die stacking is a newer technology, with a good deal of
> research into a variety of techniques.  It is already in use for
> symmetrical designs such as multi-die DRAM and Flash packages.  But the
> real benefit will come with DRAM dies connected to processor or FPGA
> dies.  Rather than having a 64-bit wide databus with powerful
> bi-directional drivers, complex serialisation/deserialisation hardware,
> PLL's, etc., a 20-bit address/command bus with tracking of pages,
> pre-fetches, etc., you could just have a full-duplex 512-bit wide
> databus and full address bus, with everything running at a lower clock
> rate and data lines driven over a distance of a mm or two.  Total system
> power would be cut drastically, as would latency, and you could drop
> much of the complex interface and control circuitry on both sides of the
> link.  Your DRAM starts to look more like wide tightly-coupled SRAM -
> your processor can drop all but its L0 cache.
>
> There are still many manufacturing challenges to overcome, and heat
> management is hard, but it will come - the potential benefits are enormous.

You are talking about an entirely different world than I am.  You are 
still talking about the markets Xilinx and Altera are going for, large 
fast FPGAs.  Only expensive parts can use multiple die packages and the 
large complex functions you are describing.  That is exactly what I 
don't need or want.

Look at the data sheet for a 64 pin ARM CM3 CPU chip.  You will find 
lots of Flash, RAM and analog peripherals.  None of them work poorly. 
They sell TONS of them, literally.

MCU makers are afraid of FPGAs and don't have access to the patents. 
FPGA makers have their telecom blinders on and now, with Microsoft 
getting into the server hardware market, that may be the next big thing 
for FPGAs.

That's my point.  There is no reason why smaller devices can't be made 
like the SmartFusion and SmartFusion2.  Even those parts are more FPGA 
than MCU with hundreds of pins and large packages.  I would like to see 
products just like a 64 pin MCU with some analog, clock oscillators, 
brownout, etc.  There is no technical reason why this can't be done.

-- 

Rick C

Article: 159380
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a Second
From: Anssi Saari <as@sci.fi>
Date: Tue, 18 Oct 2016 13:52:12 +0300
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

>  Even analog is used in MCUs, why can't FPGAs be made with the same
> processes giving us programmable logic combined with a variety of ADC,
> DAC and comparators on the same die.  Put them in smaller packages
> (lower pin counts, not the micro pitch BGAs) and let them to be used
> like MCUs.

> Maybe the market just isn't there.

How many would you buy if the product existed? Do you know others with
your kind of needs?

I'd say anyone who seriously wanted to do an "everything" chip thing
would need to have both FPGA and MCU know how and customers. That would
mean basically Xilinx buying up some MCU company or vice versa. Doesn't
seem likely. Xilinx did announce some slightly lower end parts with the
new Spartan 7s (with ADC) and single core Zynqs but they aren't even
close to what you want. I think Altera's Max 10 is a little bit closer
(flash + ADC).

Maybe if some MCU company bought Lattice? But why would an MCU company
ever think they need HW programmability if they don't know a first thing
about it? I don't think Lattice has the money to buy anyone. Intel's
acquisition of Altera got them more high priced chip business which is
what they seem want instead of cheap chips.

Article: 159381
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a Second
From: quiasmox@yahoo.com
Date: Tue, 18 Oct 2016 10:23:57 -0500
Links: << >>  << T >>  << A >>
On Mon, 17 Oct 2016 04:00:55 -0400, rickman <gnuarm@gmail.com> wrote:

>On 10/16/2016 11:00 PM, quiasmox@yahoo.com wrote:
>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman <gnuarm@gmail.com> wrote:
>>
>>> I found this pretty impressive.
>>
>> Translates it where? Across the room?
>> To what? Rot13?
>
>Did you read the article?  They are designing Internet servers that will 
>operate much faster and at lower power levels.  I believe a translation 
>app is being used as a benchmark.  It's not like websites are never 
>translated.

I did read it. It was no more specific than the headline.

-- 
John

Article: 159382
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Oct 2016 16:09:56 -0400
Links: << >>  << T >>  << A >>
On 10/18/2016 6:52 AM, Anssi Saari wrote:
> rickman <gnuarm@gmail.com> writes:
>
>>  Even analog is used in MCUs, why can't FPGAs be made with the same
>> processes giving us programmable logic combined with a variety of ADC,
>> DAC and comparators on the same die.  Put them in smaller packages
>> (lower pin counts, not the micro pitch BGAs) and let them to be used
>> like MCUs.
>
>> Maybe the market just isn't there.
>
> How many would you buy if the product existed? Do you know others with
> your kind of needs?
>
> I'd say anyone who seriously wanted to do an "everything" chip thing
> would need to have both FPGA and MCU know how and customers. That would
> mean basically Xilinx buying up some MCU company or vice versa. Doesn't
> seem likely. Xilinx did announce some slightly lower end parts with the
> new Spartan 7s (with ADC) and single core Zynqs but they aren't even
> close to what you want. I think Altera's Max 10 is a little bit closer
> (flash + ADC).

Really?  You have to buy an MCU company to add a CPU to an FPGA?  Xilinx 
already makes the Zynq with an ARM.  Seems adding ARMs to any digital 
chip these days is like falling off a log.  No need to buy anything 
remotely like a company.  Maybe a couple of good engineers from an MCU 
company.

I was not aware of the MAX 10.  I don't peruse the Altera or Xilinx 
sites much anymore.  The MAX 10 has an interesting ADC, but only one. 
It could be multiplexed and integrated to produce a pair of 48 kHz, 15 
bit data streams.  Not quite 16 bits, but close. No direct support for 
DAC and none of the other MCU features (that I could find in a brief 
look) like internal clock oscillator, internal POR, brownout detector, 
clock divider for low power operation, etc, etc, etc.


> Maybe if some MCU company bought Lattice? But why would an MCU company
> ever think they need HW programmability if they don't know a first thing
> about it? I don't think Lattice has the money to buy anyone. Intel's
> acquisition of Altera got them more high priced chip business which is
> what they seem want instead of cheap chips.

Or any company who makes FPGAs can integrate an ARM... oh, wait!  All 
four of them have!  Five if you count Atmel who made an old FPGA with an 
8 bit processor (may have been an AVR).

The problem has nearly nothing to do with integrating a digital CPU into 
the digital FPGA, that's falling off a log.  Making it work in place of 
an MCU with all the features is the part that seems to be missing.

I don't know for sure why this hasn't happened to date.  There are the 
reasons I've been told and the reasons that I think.  Who knows what 
they really are.  I believe an FPGA + a full MCU would be a big winner. 
I have a board design that I was going to redo as the FPGA is EOL.  The 
combo of an MCU, small FPGA (3000 4LUTs would be gravy for the fast 
interfaces) and the equivalent of a 16 bit, 48 kHz stereo CODEC would be 
all my digital logic in one package, well, all of it if the I/Os are 5 
volt tolerant, lol.  I have to use a pair of largish quick switches to 
interface some 10 signals from a 5 volt interface.  Then it needs to be 
in an MCU package (64/100 pin QFP and/or QFN).  The FPGA really doesn't 
need to be at all fast for most designs.  If it ran half as fast as an 
FPGA in the same process node, that would handle some 99% of designs I 
expect.  I've only worked on one where we were pushing the speed of the 
part and that was an existing part in a some 5-8 year old product, the 
TTC T-Berd.  We were asking it to handle an interface that was 4 times 
faster than the interface it was designed to handle originally.  Usually 
it is more the density, that is trying to use all the LUTs in the part. 
Usually there isn't enough routing to get much past 80 or 90 percent at 
best.

-- 

Rick C

Article: 159383
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: o pere o <me@somewhere.net>
Date: Wed, 19 Oct 2016 10:42:16 +0200
Links: << >>  << T >>  << A >>
On 18/10/16 17:23, quiasmox@yahoo.com wrote:
> On Mon, 17 Oct 2016 04:00:55 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> On 10/16/2016 11:00 PM, quiasmox@yahoo.com wrote:
>>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman <gnuarm@gmail.com> wrote:
>>>
>>>> I found this pretty impressive.
>>>
>>> Translates it where? Across the room?
>>> To what? Rot13?
>>
>> Did you read the article?  They are designing Internet servers that will
>> operate much faster and at lower power levels.  I believe a translation
>> app is being used as a benchmark.  It's not like websites are never
>> translated.
>
> I did read it. It was no more specific than the headline.
>
Same here. Just headlines and no content.

Article: 159384
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Wed, 19 Oct 2016 11:28:36 -0400
Links: << >>  << T >>  << A >>
On 10/19/2016 4:42 AM, o pere o wrote:
> On 18/10/16 17:23, quiasmox@yahoo.com wrote:
>> On Mon, 17 Oct 2016 04:00:55 -0400, rickman <gnuarm@gmail.com> wrote:
>>
>>> On 10/16/2016 11:00 PM, quiasmox@yahoo.com wrote:
>>>> On Sun, 16 Oct 2016 20:22:29 -0400, rickman <gnuarm@gmail.com> wrote:
>>>>
>>>>> I found this pretty impressive.
>>>>
>>>> Translates it where? Across the room?
>>>> To what? Rot13?
>>>
>>> Did you read the article?  They are designing Internet servers that will
>>> operate much faster and at lower power levels.  I believe a translation
>>> app is being used as a benchmark.  It's not like websites are never
>>> translated.
>>
>> I did read it. It was no more specific than the headline.
>>
> Same here. Just headlines and no content.

The content is that they are building very much faster servers as well 
as much lower power.  What other content would you like to see?  The 
development is not done but it is pretty clear they are on to something 
significant.  No?

-- 

Rick C

Article: 159385
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a Second
From: thomas.entner99@gmail.com
Date: Wed, 19 Oct 2016 16:47:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
> What other content would you like to see? =20

They claim something impressive ("Translate Wikipedia in less than a Tenth =
of a Second") but give no details about the task nor the system.

If the claim is not total marketing nonsense I would imply that they mean t=
ranslating from one language to another (e.g. English to German).

From the article link (and the picture) you could also imply that one FPGA =
(or the card in the hand of the guy) does this. But this is simply unbeliev=
able. So the question is: How many FPGAs are involved? With out this, the c=
laimed time is simply not meaningful, as double the number of FPGA will mea=
n half the time (every Wikipedia article can be translated individually, so=
 it is easy to execute the task in parallel...).

But I guess this is all not Microsoft's fault, but the problem of that spec=
ific link. I found following which gives much more insight at the end of th=
e page:
https://www.top500.org/news/microsoft-goes-all-in-for-fpgas-to-build-out-cl=
oud-based-ai/

There it says that 4 FPGAs (Stratix V D5, ca. 500k LE) would require 4 hour=
s to translate Wikipedia. The 0.1 seconds are achieved with a huge cloud of=
 such FPGA equipped systems...

Of course still impressive, but not the same as most people might think aft=
er reading the headline. (And it also makes me wonder about the future of t=
he Altera/Intel low cost FPGAs, when to want to sell a Stratix into every s=
erver...)

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG Codec


Article: 159386
Subject: Re: Free timing diagram drawing software
From: wavemediagram@gmail.com
Date: Fri, 21 Oct 2016 14:48:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
May I suggest Waveme?

waveme.weebly.com

It is a new, free, GUI-based, digital timing diagram drawing software for Windows (and Linux/MacOS via Wine).

Waveme is intended primarily for documentation purposes,
where a diagram can be exported (stored) to an image file (PNG, BMP or TIFF) or a PDF document.

Waveme can be used to draw waveforms (signals and buses), gaps, arrows and labels (see attached images).

Article: 159387
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: Jasen Betts <jasen@xnet.co.nz>
Date: 21 Oct 2016 22:40:44 GMT
Links: << >>  << T >>  << A >>
On 2016-10-18, quiasmox@yahoo.com <quiasmox@yahoo.com> wrote:
>
> I did read it. It was no more specific than the headline.
>

It could be that it was merely translating from wiki markup to HTML


-- 
This email has not been checked by half-arsed antivirus software 

Article: 159388
Subject: Re: Free timing diagram drawing software
From: Allan Herriman <allanherriman@hotmail.com>
Date: 22 Oct 2016 05:36:16 GMT
Links: << >>  << T >>  << A >>
On Fri, 21 Oct 2016 14:48:43 -0700, wavemediagram wrote:

> May I suggest Waveme?
> 
> waveme.weebly.com
> 
> It is a new, free, GUI-based, digital timing diagram drawing software
> for Windows (and Linux/MacOS via Wine).
> 
> Waveme is intended primarily for documentation purposes,
> where a diagram can be exported (stored) to an image file (PNG, BMP or
> TIFF) or a PDF document.

You need to add SVG or other vector formats to that list.  Possibly EPS 
as well.
Bitmap formats (PNG, BMP, TIFF) aren't really that great for exporting 
something that is inherently vector based.

Allan

Article: 159389
Subject: entity component binding issue with configurations
From: Marvin L <user123random@gmail.com>
Date: Sun, 23 Oct 2016 00:15:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have binding warnings http://paste2.org/La9jIxbF with http://paste2.org/wnHDY0g3   How do I solve them ?   even I modify the configuration as in http://paste2.org/bJZJPdWt , I have this error http://paste2.org/BLW1yg32 

Article: 159390
Subject: Re: entity component binding issue with configurations
From: Allan Herriman <allanherriman@hotmail.com>
Date: 23 Oct 2016 09:17:55 GMT
Links: << >>  << T >>  << A >>
On Sun, 23 Oct 2016 00:15:03 -0700, Marvin L wrote:

> I have binding warnings http://paste2.org/La9jIxbF with
> http://paste2.org/wnHDY0g3   How do I solve them ?   even I modify the
> configuration as in http://paste2.org/bJZJPdWt , I have this error
> http://paste2.org/BLW1yg32


The first error message:
key_expansion.vhd:46:1:warning: 's0' is not bound

Line 46 looks like this:
s0: subbytes port map ( sbox_in => tmp_w(23 downto 16) , sbox_out => 
subword(31 downto 24) );

Your component declaration looks ok (based on what I would expect subbytes 
to look like).

Did you remember to compile subbytes.vhd?


BTW, you can download free versions of AES crypto engine VHDL source in 
all shapes an sizes.  Many of them will even work correctly.

Regards,
Allan

Article: 159391
Subject: Re: entity component binding issue with configurations
From: Marvin L <user123random@gmail.com>
Date: Sun, 23 Oct 2016 08:49:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 23, 2016 at 5:17:57 PM UTC+8, Allan Herriman wrote:
> On Sun, 23 Oct 2016 00:15:03 -0700, Marvin L wrote:
> 
> > I have binding warnings http://paste2.org/La9jIxbF with
> > http://paste2.org/wnHDY0g3   How do I solve them ?   even I modify the
> > configuration as in http://paste2.org/bJZJPdWt , I have this error
> > http://paste2.org/BLW1yg32
> 
> 
> The first error message:
> key_expansion.vhd:46:1:warning: 's0' is not bound
> 
> Line 46 looks like this:
> s0: subbytes port map ( sbox_in => tmp_w(23 downto 16) , sbox_out => 
> subword(31 downto 24) );
> 
> Your component declaration looks ok (based on what I would expect subbytes 
> to look like).
> 
> Did you remember to compile subbytes.vhd?
> 
> 
> BTW, you can download free versions of AES crypto engine VHDL source in 
> all shapes an sizes.  Many of them will even work correctly.
> 
> Regards,
> Allan

I have solved the problem. I forgot to compile subbytes.vhd and round_constant.vhd together with key_expansion.vhd  but in gHDL, I open in .ghw format but I still could not view internal signals such as w0, w1, w2, w3, temp_w    WHY ?

Article: 159392
Subject: Re: entity component binding issue with configurations
From: Marvin L <user123random@gmail.com>
Date: Sun, 23 Oct 2016 18:58:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 23, 2016 at 11:49:37 PM UTC+8, Marvin L wrote:
> On Sunday, October 23, 2016 at 5:17:57 PM UTC+8, Allan Herriman wrote:
> > On Sun, 23 Oct 2016 00:15:03 -0700, Marvin L wrote:
> >=20
> > > I have binding warnings http://paste2.org/La9jIxbF with
> > > http://paste2.org/wnHDY0g3   How do I solve them ?   even I modify th=
e
> > > configuration as in http://paste2.org/bJZJPdWt , I have this error
> > > http://paste2.org/BLW1yg32
> >=20
> >=20
> > The first error message:
> > key_expansion.vhd:46:1:warning: 's0' is not bound
> >=20
> > Line 46 looks like this:
> > s0: subbytes port map ( sbox_in =3D> tmp_w(23 downto 16) , sbox_out =3D=
>=20
> > subword(31 downto 24) );
> >=20
> > Your component declaration looks ok (based on what I would expect subby=
tes=20
> > to look like).
> >=20
> > Did you remember to compile subbytes.vhd?
> >=20
> >=20
> > BTW, you can download free versions of AES crypto engine VHDL source in=
=20
> > all shapes an sizes.  Many of them will even work correctly.
> >=20
> > Regards,
> > Allan
>=20
> I have solved the problem. I forgot to compile subbytes.vhd and round_con=
stant.vhd together with key_expansion.vhd  but in gHDL, I open in .ghw form=
at but I still could not view internal signals such as w0, w1, w2, w3, temp=
_w    WHY ?

I could not view the internal signal http://i.imgur.com/w4jwnN1.png even th=
ough I am using the formal format *ghw with http://paste2.org/mVMOJZYA , ht=
tp://paste2.org/vpbvXcID , http://paste2.org/1pAZac73 , http://paste2.org/F=
Dh4c6Av and http://paste2.org/UwgnBnds

Article: 159393
Subject: verilog code
From: koradaprudvi@gmail.com
Date: Mon, 24 Oct 2016 02:52:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi,

i want verilog code for RS232

Article: 159394
Subject: Re: verilog code
From: cfbsoftware@gmail.com
Date: Mon, 24 Oct 2016 05:40:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 24, 2016 at 8:22:59 PM UTC+10:30, korada...@gmail.com wrote:
> hi,
> 
> i want verilog code for RS232

https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

(RS232T.v and RS232R.v)

 

Article: 159395
Subject: Re: verilog code
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 24 Oct 2016 09:05:11 -0400
Links: << >>  << T >>  << A >>
cfbsoftware@gmail.com wrote:
> On Monday, October 24, 2016 at 8:22:59 PM UTC+10:30, korada...@gmail.com wrote:
>> hi,
>>
>> i want verilog code for RS232
> 
> https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html
> 
> (RS232T.v and RS232R.v)
> 
>  

Both the question and the answer are mis-using the term RS232.  RS232 is
only an electrical interface standard defining the voltages used for
a standard modem interface.  What the Verilog code does, and I presume
what the OP asked for is called a UART.  To have communication over
RS232 you typically need both a UART (or USART) and an electrical
interface (drivers and receivers or transceivers) to convert the
LVCMOS signals to RS232 levels.

-- 
Gabor

Article: 159396
Subject: Re: Microsoft's FPGA Translates Wikipedia in less than a Tenth of a
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Oct 2016 11:06:48 -0400
Links: << >>  << T >>  << A >>
On 10/19/2016 7:47 PM, thomas.entner99@gmail.com wrote:
>> What other content would you like to see?
>
> They claim something impressive ("Translate Wikipedia in less than a Tenth of a Second") but give no details about the task nor the system.
>
> If the claim is not total marketing nonsense I would imply that they mean translating from one language to another (e.g. English to German).
>
> From the article link (and the picture) you could also imply that one FPGA (or the card in the hand of the guy) does this. But this is simply unbelievable. So the question is: How many FPGAs are involved? With out this, the claimed time is simply not meaningful, as double the number of FPGA will mean half the time (every Wikipedia article can be translated individually, so it is easy to execute the task in parallel...).
>
> But I guess this is all not Microsoft's fault, but the problem of that specific link. I found following which gives much more insight at the end of the page:
> https://www.top500.org/news/microsoft-goes-all-in-for-fpgas-to-build-out-cloud-based-ai/
>
> There it says that 4 FPGAs (Stratix V D5, ca. 500k LE) would require 4 hours to translate Wikipedia. The 0.1 seconds are achieved with a huge cloud of such FPGA equipped systems...
>
> Of course still impressive, but not the same as most people might think after reading the headline. (And it also makes me wonder about the future of the Altera/Intel low cost FPGAs, when to want to sell a Stratix into every server...)

For sure the release is short of engineering data... it *is* a marketing 
pitch.  The point is they plan to be providing a combination of FPGA and 
CPU which will run much faster and use less power than the CPU alone. 
No, they aren't offering hard numbers and the task of translating 
wikipedia is not really the best benchmark for serving up or searching 
web pages.  It is meant to offer a metric that even laymen can relate to.

In other words, it's meant to sound good to those who would not 
understand more engineering information.

Microsoft has no incentive to sell FPGAs.  Their incentive is to provide 
the software on faster hardware.  If the hardware doesn't pan out, 
Microsoft gets nothing but expenses.

-- 

Rick C

Article: 159397
Subject: Re: Free timing diagram drawing software
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Oct 2016 11:17:25 -0400
Links: << >>  << T >>  << A >>
On 10/21/2016 5:48 PM, wavemediagram@gmail.com wrote:
> May I suggest Waveme?
>
> waveme.weebly.com
>
> It is a new, free, GUI-based, digital timing diagram drawing software for Windows (and Linux/MacOS via Wine).
>
> Waveme is intended primarily for documentation purposes,
> where a diagram can be exported (stored) to an image file (PNG, BMP or TIFF) or a PDF document.
>
> Waveme can be used to draw waveforms (signals and buses), gaps, arrows and labels (see attached images).

This is "free" software in the sense of "free beer", but not as in "free 
speech", right?  It doesn't appear that there is an interest in making 
money from this, at least not for now.  Why not make it open source?

I've seen too many special purpose graphical tools go by the wayside to 
consider spending time to learn a tool like this that I would only use 
sporadically.  If this tool ends up with no support I don't think I 
would want to be using it unless the source were available.

I have an email program like that which I don't want to stop using 
because it works well and I'd have a learning curve to switch.  But no 
more bug fixes and one of these days it won't port to the new machine.

-- 

Rick C

Article: 159398
Subject: Re: Free timing diagram drawing software
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 24 Oct 2016 10:33:07 -0500
Links: << >>  << T >>  << A >>
On 10/24/2016 10:17 AM, rickman wrote:
> On 10/21/2016 5:48 PM, wavemediagram@gmail.com wrote:
>> May I suggest Waveme?
>>
>> waveme.weebly.com
>>
>> It is a new, free, GUI-based, digital timing diagram drawing software
>> for Windows (and Linux/MacOS via Wine).
>>
>> Waveme is intended primarily for documentation purposes,
>> where a diagram can be exported (stored) to an image file (PNG, BMP or
>> TIFF) or a PDF document.
>>
>> Waveme can be used to draw waveforms (signals and buses), gaps, arrows
>> and labels (see attached images).
>
> This is "free" software in the sense of "free beer", but not as in "free
> speech", right?  It doesn't appear that there is an interest in making
> money from this, at least not for now.  Why not make it open source?
>
> I've seen too many special purpose graphical tools go by the wayside to
> consider spending time to learn a tool like this that I would only use
> sporadically.  If this tool ends up with no support I don't think I
> would want to be using it unless the source were available.
>
> I have an email program like that which I don't want to stop using
> because it works well and I'd have a learning curve to switch.  But no
> more bug fixes and one of these days it won't port to the new machine.
>
Eudora?

-- 
Cecil - k5nwa

Article: 159399
Subject: Re: Free timing diagram drawing software
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Oct 2016 14:02:59 -0400
Links: << >>  << T >>  << A >>
On 10/24/2016 11:33 AM, Cecil Bayona wrote:
> On 10/24/2016 10:17 AM, rickman wrote:
>> On 10/21/2016 5:48 PM, wavemediagram@gmail.com wrote:
>>> May I suggest Waveme?
>>>
>>> waveme.weebly.com
>>>
>>> It is a new, free, GUI-based, digital timing diagram drawing software
>>> for Windows (and Linux/MacOS via Wine).
>>>
>>> Waveme is intended primarily for documentation purposes,
>>> where a diagram can be exported (stored) to an image file (PNG, BMP or
>>> TIFF) or a PDF document.
>>>
>>> Waveme can be used to draw waveforms (signals and buses), gaps, arrows
>>> and labels (see attached images).
>>
>> This is "free" software in the sense of "free beer", but not as in "free
>> speech", right?  It doesn't appear that there is an interest in making
>> money from this, at least not for now.  Why not make it open source?
>>
>> I've seen too many special purpose graphical tools go by the wayside to
>> consider spending time to learn a tool like this that I would only use
>> sporadically.  If this tool ends up with no support I don't think I
>> would want to be using it unless the source were available.
>>
>> I have an email program like that which I don't want to stop using
>> because it works well and I'd have a learning curve to switch.  But no
>> more bug fixes and one of these days it won't port to the new machine.

Yeah.  I use T-bird for newsgroups, but I've never gotten used to how it 
would work with filters and such for my regular email.  Eudora is a 
great program, but some day I won't be able to use it anymore.

-- 

Rick C



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