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 159750

Article: 159750
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Fri, 24 Feb 2017 04:21:52 -0500
Links: << >>  << T >>  << A >>
On 2/24/2017 2:32 AM, kristoff wrote:
> Hi all,
>
> A couple of weeks ago, I was watching the talk of Wolf Clifford on his
> opensource fpga flow at ccc.
> (https://www.youtube.com/watch?v=SOn0g3k0FlE)
>
>
> At the end, he mentions designing an open-source fpga and the replies he
> got when he mentioned the idea to hardware-companies. Appart from the
> question about the usefullness or economic viability of the idea itself
> (1), it did get me thinking.
>
>
> Question, can I conclude from his remark that -if a hardware companie
> would start out with designing a fpga- that the problem is more the
> "software" side of things than the actual hardware design of the chip.
>
>
> Or is this conclussion a bit to easy?

Nearly two decades ago (well, 15 years anyway) folks from Xilinx said 
they spent more on software development than developing the chips.

-- 

Rick C

Article: 159751
Subject: Re: designing a fpga
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Fri, 24 Feb 2017 14:38:51 +0100
Links: << >>  << T >>  << A >>
On 02/24/2017 08:32 AM, kristoff wrote:
> Hi all,
> 
> A couple of weeks ago, I was watching the talk of Wolf Clifford on his opensource fpga flow at ccc.
> (https://www.youtube.com/watch?v=SOn0g3k0FlE)
> 
> 
> At the end, he mentions designing an open-source fpga and the replies he got when he mentioned the idea to hardware-companies. Appart from the question about the usefullness or economic viability of the idea itself (1), it did get me thinking.
> 
> 
> Question, can I conclude from his remark that -if a hardware companie would start out with designing a fpga- that the problem is more the "software" side of things than the actual hardware design of the chip.
> 
> 
> Or is this conclussion a bit to easy?
> 
> 
> 
> Cheerio! Kr. Bonne.
> 
> 

Hodgin posted this link a while ago:
https://www.youtube.com/watch?v=1oG-3XWLgog



Article: 159752
Subject: Re: designing a fpga
From: Jon Elson <elson@pico-systems.com>
Date: Fri, 24 Feb 2017 10:35:39 -0600
Links: << >>  << T >>  << A >>
rickman wrote:

> On 2/24/2017 2:32 AM, kristoff wrote:
>> Hi all,
>>
>> A couple of weeks ago, I was watching the talk of Wolf Clifford on his
>> opensource fpga flow at ccc.
>> (https://www.youtube.com/watch?v=SOn0g3k0FlE)
>>
>>
>> At the end, he mentions designing an open-source fpga and the replies he
>> got when he mentioned the idea to hardware-companies. Appart from the
>> question about the usefullness or economic viability of the idea itself
>> (1), it did get me thinking.
>>
>>
>> Question, can I conclude from his remark that -if a hardware companie
>> would start out with designing a fpga- that the problem is more the
>> "software" side of things than the actual hardware design of the chip.
>>
>>
>> Or is this conclussion a bit to easy?
> 
> Nearly two decades ago (well, 15 years anyway) folks from Xilinx said
> they spent more on software development than developing the chips.
> 
It is easy to believe this is true.  The FPGA needs a fair bit of careful 
design and testing, but the structure is quite simple.  You need to make 
sure the LUTs are glitchless and that you know the timings.  That is about 
it.

THEN, you get to the software side.  You need to be able to take in all the 
suboptimal and blatantly bad HDL that users will throw at it, and at least 
give coherent error messages and not crash.  There are probably so MANY ways 
to write bad HDL that has unintended side effects, races and logic hazards.
While the FPGA is a massively repeated set of very simple identical cells, 
the software has to treat it as thousands of different components once the 
LUT patterns have been loaded.  I'm GLAD somebody else is doing all this 
work!

To make your own FPGA, probably the BIGGEST minefield is the patent arena.  
There must be thousands of current patents on FPGAs and FPGA-like devices 
and tons of old prior art that could make patenting anything you design 
problematic.  Even if you had no intention of filing for a patent, you'd 
have to design very carefully so as not to step on one of the "big boys" 
patents.  There is also lots of prtections files on software IP that you'd 
have to avoid.

Jon

Article: 159753
Subject: Re: designing a fpga
From: Jecel <jecel@merlintec.com>
Date: Fri, 24 Feb 2017 09:23:47 -0800 (PST)
Links: << >>  << T >>  << A >>
In 2004 ST started the most serious Open FPGA project I am aware of:

http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp

Sadly they gave up in early 2005.

-- Jecel

Article: 159754
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Fri, 24 Feb 2017 15:40:27 -0500
Links: << >>  << T >>  << A >>
On 2/24/2017 11:35 AM, Jon Elson wrote:
> rickman wrote:
>
>> On 2/24/2017 2:32 AM, kristoff wrote:
>>> Hi all,
>>>
>>> A couple of weeks ago, I was watching the talk of Wolf Clifford on his
>>> opensource fpga flow at ccc.
>>> (https://www.youtube.com/watch?v=SOn0g3k0FlE)
>>>
>>>
>>> At the end, he mentions designing an open-source fpga and the replies he
>>> got when he mentioned the idea to hardware-companies. Appart from the
>>> question about the usefullness or economic viability of the idea itself
>>> (1), it did get me thinking.
>>>
>>>
>>> Question, can I conclude from his remark that -if a hardware companie
>>> would start out with designing a fpga- that the problem is more the
>>> "software" side of things than the actual hardware design of the chip.
>>>
>>>
>>> Or is this conclussion a bit to easy?
>>
>> Nearly two decades ago (well, 15 years anyway) folks from Xilinx said
>> they spent more on software development than developing the chips.
>>
> It is easy to believe this is true.  The FPGA needs a fair bit of careful
> design and testing, but the structure is quite simple.  You need to make
> sure the LUTs are glitchless and that you know the timings.  That is about
> it.

I think you are oversimplifying the design of an FPGA by quite a large 
margin.  I believe the most important part of FPGAs is the routing and 
overall architecture.  I am sure they put tons of effort into optimizing 
every aspect of the logic as well as the routing for timing and power 
consumption, the two most important parameters of FPGAs.

The design of all the various special functions take no small amount of 
effort too, the clock blocks are a good example.  Then there are 
multipliers and memory, all of which must be optimized for the process. 
In fact, my understanding is that the FPGA vendors are a large 
contributor to the development of the processes used at the foundries.


> THEN, you get to the software side.  You need to be able to take in all the
> suboptimal and blatantly bad HDL that users will throw at it, and at least
> give coherent error messages and not crash.  There are probably so MANY ways
> to write bad HDL that has unintended side effects, races and logic hazards.
> While the FPGA is a massively repeated set of very simple identical cells,
> the software has to treat it as thousands of different components once the
> LUT patterns have been loaded.  I'm GLAD somebody else is doing all this
> work!

I don't think writing code to read text and not crash is actually all 
that hard.  The tool vendors don't care about logic hazards, that is the 
domain of the designer.


> To make your own FPGA, probably the BIGGEST minefield is the patent arena.
> There must be thousands of current patents on FPGAs and FPGA-like devices
> and tons of old prior art that could make patenting anything you design
> problematic.  Even if you had no intention of filing for a patent, you'd
> have to design very carefully so as not to step on one of the "big boys"
> patents.  There is also lots of prtections files on software IP that you'd
> have to avoid.

Certainly if you wish to make a state of the art FPGA it would involve 
dodging a great many patents.  But to design *a* FPGA would not be so 
hard.  In fact expired patents would be your pool of resources to draw 
from.  The basic LUT used as logic and memory are out of patent along 
with everything used in devices like the XC4000 series.  If I were 
designing a chip and wanted to include FPGA fabric, I could do worse 
than to duplicate the functionality of that device.

-- 

Rick C

Article: 159755
Subject: Re: designing a fpga
From: Jon Elson <elson@pico-systems.com>
Date: Fri, 24 Feb 2017 22:30:19 -0600
Links: << >>  << T >>  << A >>
rickman wrote:


> 
> I think you are oversimplifying the design of an FPGA by quite a large
> margin.  I believe the most important part of FPGAs is the routing and
> overall architecture.  I am sure they put tons of effort into optimizing
> every aspect of the logic as well as the routing for timing and power
> consumption, the two most important parameters of FPGAs.
> 
OK, yes, I WAS oversimplifying.  My point (badly stated) was that the FPGA 
designers hold all the cards, they fully specify the LUTs, the routing 
matrix, the IOBs, etc.  The SOFTWARE, however, has to deal with all the 
pathological and just totally unexpected things people will try to do with 
an FPGA.  How about designing your own ring oscillator?
> The design of all the various special functions take no small amount of
> effort too, the clock blocks are a good example.  Then there are
> multipliers and memory, all of which must be optimized for the process.
> In fact, my understanding is that the FPGA vendors are a large
> contributor to the development of the processes used at the foundries.
> 
Yes, I can believe that, too.  They really push the boundaries of what can 
be done in a process.
> 

> 
> I don't think writing code to read text and not crash is actually all
> that hard.  The tool vendors don't care about logic hazards, that is the
> domain of the designer.
> 
> 
OK, maybe not "crash", but produce unintelligable error messages, or just 
totally screwy results, with NO error messages.  Yes, now I must admit, some 
of my legacy designs that have been dragged along from 5V Spartan to Spartan 
2E to Spartan 3A still have a bunch of crud left over from their old history 
and mediocre hacking.  But, I've had a few situations where ISE didn't like 
what I'd given it, and had to just recompose some portion of the logic.  I 
never understood what was wrong with my VHDL, but changing the way I'd 
written the equations just slightly made it work.  Fortunately, I have had 
very few of these situations, and for the most part ISE works amazingly 
well, and I'm NOT complaining.  I'm just aware that there are so many ways 
to structure HDLs, and so many things one can do with it, that it seems very 
complicated to make it all work.

Jon

Article: 159756
Subject: Master Xilinx FPGA like Jtag bridge.
From: abirov@gmail.com
Date: Fri, 24 Feb 2017 21:21:11 -0800 (PST)
Links: << >>  << T >>  << A >>
How to make master FPGA to connect to many FPGAs ?

Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO and TD=
I connect to master fpga, master fpga has TMS TDI TDO TCK connected and wor=
king to pc normally, it need to make connection JTAG of two fpgas to other =
4 ports or somehow can connect to master's jtag port ?

Article: 159757
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: abirov@gmail.com
Date: Fri, 24 Feb 2017 21:31:14 -0800 (PST)
Links: << >>  << T >>  << A >>
|---------|-TMS----|------------|-TMS----
| FPGA 0  |-TCK----|            |-TCK----
|         |-TDO----|            |-TDO----
|---------|        |            |-TDI----
    |              |            |
   TDI             |            |
    |              |            |
    |              | MASTER FPGA|
    |              |            |
   TDO             |            |
    |              |            |
|---------|-TMS----|            |
| FGPA 1  |-TCK----|            |
|         |-TDI----|            |
|---------|        |------------|

Article: 159758
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: abirov@gmail.com
Date: Fri, 24 Feb 2017 21:33:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com wrote=
:
> How to make master FPGA to connect to many FPGAs ?
>=20
> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO and =
TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected and w=
orking to pc normally, it need to make connection JTAG of two fpgas to othe=
r 4 ports or somehow can connect to master's jtag port ?

|   |---------|-TMS----|------------|-TMS----
|   | FPGA 0  |-TCK----|            |-TCK----
|   |         |-TDO----|            |-TDO----
|   |---------|        |            |-TDI----
|       |              |            |
|      TDI             |            |
|       |              |            |
|       |              | MASTER FPGA|
|       |              |            |
|      TDO             |            |
|       |              |            |
|   |---------|-TMS----|            |
|   | FGPA 1  |-TCK----|            |
|   |         |-TDI----|            |
|   |---------|        |------------|

Article: 159759
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Sat, 25 Feb 2017 04:19:01 -0500
Links: << >>  << T >>  << A >>
On 2/24/2017 11:30 PM, Jon Elson wrote:
> rickman wrote:
>
>
>>
>> I think you are oversimplifying the design of an FPGA by quite a large
>> margin.  I believe the most important part of FPGAs is the routing and
>> overall architecture.  I am sure they put tons of effort into optimizing
>> every aspect of the logic as well as the routing for timing and power
>> consumption, the two most important parameters of FPGAs.
>>
> OK, yes, I WAS oversimplifying.  My point (badly stated) was that the FPGA
> designers hold all the cards, they fully specify the LUTs, the routing
> matrix, the IOBs, etc.  The SOFTWARE, however, has to deal with all the
> pathological and just totally unexpected things people will try to do with
> an FPGA.  How about designing your own ring oscillator?

I'm not sure how to even do that in an HDL.  I suppose you can have a 
second input to each inverter and set bits in a register to enable it. 
But it would still have an combinatorial feedback path which would flag 
an error in the timing analyzer unless you except that path.  Where do 
you see the problem?

The tools don't cope with a lot of crazy stuff.  If the inputs are too 
wacky, they just give an error message.


>> The design of all the various special functions take no small amount of
>> effort too, the clock blocks are a good example.  Then there are
>> multipliers and memory, all of which must be optimized for the process.
>> In fact, my understanding is that the FPGA vendors are a large
>> contributor to the development of the processes used at the foundries.
>>
> Yes, I can believe that, too.  They really push the boundaries of what can
> be done in a process.
>>
>
>>
>> I don't think writing code to read text and not crash is actually all
>> that hard.  The tool vendors don't care about logic hazards, that is the
>> domain of the designer.
>>
>>
> OK, maybe not "crash", but produce unintelligable error messages, or just
> totally screwy results, with NO error messages.  Yes, now I must admit, some
> of my legacy designs that have been dragged along from 5V Spartan to Spartan
> 2E to Spartan 3A still have a bunch of crud left over from their old history
> and mediocre hacking.  But, I've had a few situations where ISE didn't like
> what I'd given it, and had to just recompose some portion of the logic.  I
> never understood what was wrong with my VHDL, but changing the way I'd
> written the equations just slightly made it work.  Fortunately, I have had
> very few of these situations, and for the most part ISE works amazingly
> well, and I'm NOT complaining.  I'm just aware that there are so many ways
> to structure HDLs, and so many things one can do with it, that it seems very
> complicated to make it all work.

It's all rule based.  As long as you follow the rules it will 
synthesize.  I remember my first VHDL design.  I used some of the 
features that seemed useful and no one told me not to (it was an Orcad 
tool believe it or not).  It was so terrible we switched to the Xilinx 
tool (I don't recall the origin of that tool).  I was using '-' for 
don't cares in comparisons.  Then we had a tool update and Xilinx 
switched the synthesis engine on us.  The don't cares didn't work 
anymore as well as many other issues.  Back in those days I think the 
vendors tried to ignore some aspects of the VHDL standard and let you 
get away with some things and not others and of course, each vendor was 
different.  So I wrote my code three times for that project.

-- 

Rick C

Article: 159760
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: rickman <gnuarm@gmail.com>
Date: Sat, 25 Feb 2017 04:22:21 -0500
Links: << >>  << T >>  << A >>
On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
> On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com wrote:
>> How to make master FPGA to connect to many FPGAs ?
>>
>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO and TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected and working to pc normally, it need to make connection JTAG of two fpgas to other 4 ports or somehow can connect to master's jtag port ?
>
> |   |---------|-TMS----|------------|-TMS----
> |   | FPGA 0  |-TCK----|            |-TCK----
> |   |         |-TDO----|            |-TDO----
> |   |---------|        |            |-TDI----
> |       |              |            |
> |      TDI             |            |
> |       |              |            |
> |       |              | MASTER FPGA|
> |       |              |            |
> |      TDO             |            |
> |       |              |            |
> |   |---------|-TMS----|            |
> |   | FGPA 1  |-TCK----|            |
> |   |         |-TDI----|            |
> |   |---------|        |------------|
>

Why do you want the master FPGA to control the others rather than 
loading them all in one chain?  Connect all TMS and TCK lines in 
parallel and connect all TDI and TDO in one big daisy chain.  If the 
slave FPGAs are loaded by the master, where will the data come from?

-- 

Rick C

Article: 159761
Subject: Re: designing a fpga
From: kristoff <kristoff@skypro.be>
Date: Sat, 25 Feb 2017 10:39:57 +0100
Links: << >>  << T >>  << A >>
Hi Jecel, Rickman, Jon, Johann, ... all




On 24-02-17 18:23, Jecel wrote:
> In 2004 ST started the most serious Open FPGA project I am aware of:
> http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp
> Sadly they gave up in early 2005.

Interesting.


Now I do get the impression that open-source hardware (and related 
issues) is something that just now has started to become of age.
(perhaps opensparc was also years to soon).


Appart from the icestorm tool, I now found this project: Trollstigen
https://www.youtube.com/watch?v=zMZqzXfjOko

Also here:
https://www.youtube.com/watch?v=04SWPT4d9Ls


I think it's interesting in two ways:

- it's really a open-source fpga design so it proves in principe that 
this can be done.

- it seams to be based on a different flow: VTR (verilog to routing, 
https://verilogtorouting.org/) on which they added their own 
bitstream-generator

Now, i am far being an expert in fpga expert (hence all my questions 
here :-) ) but from what I understand about it, this means there are two 
options on the table:
- completely open-source: open-source fpga hardware + open-source tools
- closed-source fpga hardware + open-source tools (except for the 
bitstream generator, which would then be closed source).

I am correct, the actual knowledge of the internals of the FPGA is in 
the bitstream generator, so if a company does not want to expose that 
information, it would be enough to use a closed-source tool for that.

Well free to correct me if I am wrong.


> -- Jecel

Cheerio! Kr. Bonne.

Article: 159762
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Sat, 25 Feb 2017 05:07:05 -0500
Links: << >>  << T >>  << A >>
On 2/25/2017 4:39 AM, kristoff wrote:
> Hi Jecel, Rickman, Jon, Johann, ... all
>
>
>
>
> On 24-02-17 18:23, Jecel wrote:
>> In 2004 ST started the most serious Open FPGA project I am aware of:
>> http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp
>>
>> Sadly they gave up in early 2005.
>
> Interesting.
>
>
> Now I do get the impression that open-source hardware (and related
> issues) is something that just now has started to become of age.
> (perhaps opensparc was also years to soon).
>
>
> Appart from the icestorm tool, I now found this project: Trollstigen
> https://www.youtube.com/watch?v=zMZqzXfjOko
>
> Also here:
> https://www.youtube.com/watch?v=04SWPT4d9Ls
>
>
> I think it's interesting in two ways:
>
> - it's really a open-source fpga design so it proves in principe that
> this can be done.
>
> - it seams to be based on a different flow: VTR (verilog to routing,
> https://verilogtorouting.org/) on which they added their own
> bitstream-generator
>
> Now, i am far being an expert in fpga expert (hence all my questions
> here :-) ) but from what I understand about it, this means there are two
> options on the table:
> - completely open-source: open-source fpga hardware + open-source tools
> - closed-source fpga hardware + open-source tools (except for the
> bitstream generator, which would then be closed source).
>
> I am correct, the actual knowledge of the internals of the FPGA is in
> the bitstream generator, so if a company does not want to expose that
> information, it would be enough to use a closed-source tool for that.
>
> Well free to correct me if I am wrong.

A company can *try* to keep their chip design info closed, but if a 
bunch of amateurs can reverse engineer one company's devices, it 
shouldn't be too hard to reverse engineer them all.  It is a matter of 
time and the need.  To date no commercial effort has needed to reverse 
engineer FPGA bitstreams.  But a bunch of amateurs showed it could be 
done.

The trouble with open source hardware is that having one made is not 
inexpensive.  For board level items it is not terribly practical unless 
it is a niche item you just can't find elsewhere.  For chip level 
devices personal manufacturing is prohibitively expensive.  Even decades 
old technology is not cheap to have a minimum run made.  Ask Green Arrays.

-- 

Rick C

Article: 159763
Subject: Re: designing a fpga
From: kristoff <kristoff@skypro.be>
Date: Sat, 25 Feb 2017 13:20:07 +0100
Links: << >>  << T >>  << A >>
Hi Jon,

On 24-02-17 17:35, Jon Elson wrote:
> THEN, you get to the software side.  You need to be able to take in all the
> suboptimal and blatantly bad HDL that users will throw at it, and at least
> give coherent error messages and not crash.  There are probably so MANY ways
> to write bad HDL that has unintended side effects, races and logic hazards.
> While the FPGA is a massively repeated set of very simple identical cells,
> the software has to treat it as thousands of different components once the
> LUT patterns have been loaded.  I'm GLAD somebody else is doing all this
> work!

A couple of days ago, I found this video:
https://media.ccc.de/v/froscon2016-1817-how_to_design_your_own_chip

It's a very good overview on the tools that are out there for vlsi, fpga 
design, testing-tools, ... and how hacker/maker/hobbyist friendly they 
are, including some ways to get them foundries.

So there seams to be quite a few tools out there.
Concerning FPGAs, there seams to be two tools that go all the way up 
generating a fpga bitstream. Wolf is now working on the "timing 
verification" part for his tools.



> To make your own FPGA, probably the BIGGEST minefield is the patent arena.
> There must be thousands of current patents on FPGAs and FPGA-like devices
> and tons of old prior art that could make patenting anything you design
> problematic.  Even if you had no intention of filing for a patent, you'd
> have to design very carefully so as not to step on one of the "big boys"
> patents.  There is also lots of prtections files on software IP that you'd
> have to avoid.

I think Rickman made a valid remark that quite some technologie is based 
on patents that have expired.

This kind of reminds me of the "codec2" project 
(http://www.rowetel.com/?page_id=452).
It was also thought that low-bitrates voice codecs where littered with 
patents, but it turned out that it is possible to create a (now down-to 
700 bps) voice codec just based on public domain knowledge.


Do mind, I am not saying that this is also the cases here, just it is 
"to be verified".




Now, for me, the question that interests me is this:

For an fpga, you need two things: hardware and software.

If
- the software-component is now becoming available as open-source tools 
(and let's make the assumtion that this will continue to be the case in 
the near future),

and
- the hardware-component seams to be the less-difficult part of the 
process (especially for companies that already design and make ICs, be 
it not fpgas),

could the conclussion then be that -in a couple of years- will result in 
more competition in the fpga-market?
(probably starting at the low-end part of the market)?


Or is this conclussion a bit to easy?


> Jon
Cheerio! Kr. Bonne


Article: 159764
Subject: Re: designing a fpga
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 25 Feb 2017 06:37:46 -0800 (PST)
Links: << >>  << T >>  << A >>
I've been considering designing my own fpga to go with my Logician
tool.  I would call it Si-Block ("sigh-block," or SiB for short).  It would
allow unlimited logic with a decreasing performance level the more
complex it got, running on a saturating clock that fires maximally
at frequency, but otherwise only when each cycle completes fully.
It would be inexpensive, with full debug abilities, and room to
expand.

Stack:

    0: [SiB hardware]
    1: [Logician, simulation + SiB compiler]
    2: [HLL Compilers, able to also output to Logician]
    3: [IDE / text editors, express in some language]
    4: [Human ideas]

Thank you,
Rick C. Hodgin

Article: 159765
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 25 Feb 2017 09:50:42 -0800 (PST)
Links: << >>  << T >>  << A >>
> Question, can I conclude from his remark that -if a hardware companie 
> would start out with designing a fpga- that the problem is more the 
> "software" side of things than the actual hardware design of the chip.
> 
> 
> Or is this conclussion a bit to easy?

I'd agree with this.  I'd say the silicon these days is pretty great and the software is the limitation.  It's not for lack of effort, though.  I think most of the resources of an FPGA company go into the software side.

I don't quite understand the interest in an open-source FPGA.  I don't believe it would be better than what we are getting commercially.  

The areas that need the greatest improvement are open to development.  There's nothing stopping somebody from making a better synthesizer.  Convert HDL to structural code.  You can still use this with commercial tools.

Article: 159766
Subject: Re: designing a fpga
From: thomas.entner99@gmail.com
Date: Sat, 25 Feb 2017 17:36:14 -0800 (PST)
Links: << >>  << T >>  << A >>
Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
> > Question, can I conclude from his remark that -if a hardware companie=
=20
> > would start out with designing a fpga- that the problem is more the=20
> > "software" side of things than the actual hardware design of the chip.
> >=20
> >=20
> > Or is this conclussion a bit to easy?
>=20
> I'd agree with this.  I'd say the silicon these days is pretty great and =
the software is the limitation.  It's not for lack of effort, though.  I th=
ink most of the resources of an FPGA company go into the software side.
>=20
> I don't quite understand the interest in an open-source FPGA.  I don't be=
lieve it would be better than what we are getting commercially. =20
>=20
> The areas that need the greatest improvement are open to development.  Th=
ere's nothing stopping somebody from making a better synthesizer.  Convert =
HDL to structural code.  You can still use this with commercial tools.

I basically fully agree (except maybe that also P&R might be an interesting=
 topic which is pretty closed). But I want to add some further comments:

From a technical point, the software is the most difficult. While what Clif=
ford does with YOSYS, etc. sounds extremely impressive (I have not never te=
sted it yet - no time...), it will be next to impossible to find sufficient=
 skilled programmers (in both programming and FPGA design) that contribute =
for free, IMHO.

From a practical point, however, the hardware is much more difficult, simpl=
y because it is incredible expensive. Of course you can use a big FPGA to s=
imulate the "new" FPGA for a start. But at some point you will want to have=
 real chips for the whole project to make sense. And then you have a multi-=
million Euro/dollar project...

You have to find a business case for the one how pays this millions (if you=
 find someone at all...), and it will most likely be not open source?

The next difficult thing about hardware is (beside the patent topic others =
have already mentioned): Either you make a "me too" hardware, based on 4-in=
puts LUTs (the key patents have already expired, I guess) - or you invent s=
ome improved more or less radical new architecture. This would be a big (an=
d interesting task) on it's own, of course... Maybe, at the end of Moore's =
law (?), a clever new architecture could bring a real benefit...

Business cases that come to my mind are things like:
- new FPGA vendor
- offer embedded FPGA technology for ASIC suppliers

You will need to be able support the customers, etc. and compete against th=
e existing players. There is a reason why so many FPGA start-ups failed. Bu=
t this does not mean that it cannot be done, of course... Personally I woul=
d find it cool to have an Austrian FPGA ;-)

Regards,

Thomas

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



Article: 159767
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: abirov@gmail.com
Date: Sat, 25 Feb 2017 23:27:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, February 25, 2017 at 3:22:21 PM UTC+6, rickman wrote:
> On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
> > On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com w=
rote:
> >> How to make master FPGA to connect to many FPGAs ?
> >>
> >> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO a=
nd TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected an=
d working to pc normally, it need to make connection JTAG of two fpgas to o=
ther 4 ports or somehow can connect to master's jtag port ?
> >
> > |   |---------|-TMS----|------------|-TMS----
> > |   | FPGA 0  |-TCK----|            |-TCK----
> > |   |         |-TDO----|            |-TDO----
> > |   |---------|        |            |-TDI----
> > |       |              |            |
> > |      TDI             |            |
> > |       |              |            |
> > |       |              | MASTER FPGA|
> > |       |              |            |
> > |      TDO             |            |
> > |       |              |            |
> > |   |---------|-TMS----|            |
> > |   | FGPA 1  |-TCK----|            |
> > |   |         |-TDI----|            |
> > |   |---------|        |------------|
> >
>=20
> Why do you want the master FPGA to control the others rather than=20
> loading them all in one chain?  Connect all TMS and TCK lines in=20
> parallel and connect all TDI and TDO in one big daisy chain.  If the=20
> slave FPGAs are loaded by the master, where will the data come from?
>=20
> --=20
>=20
> Rick C

It is reverse engineering, someone did this but i just want reuse board onl=
y

Article: 159768
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: rickman <gnuarm@gmail.com>
Date: Sun, 26 Feb 2017 05:21:46 -0500
Links: << >>  << T >>  << A >>
On 2/26/2017 2:27 AM, abirov@gmail.com wrote:
> On Saturday, February 25, 2017 at 3:22:21 PM UTC+6, rickman wrote:
>> On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
>>> On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com wrote:
>>>> How to make master FPGA to connect to many FPGAs ?
>>>>
>>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO and TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected and working to pc normally, it need to make connection JTAG of two fpgas to other 4 ports or somehow can connect to master's jtag port ?
>>>
>>> |   |---------|-TMS----|------------|-TMS----
>>> |   | FPGA 0  |-TCK----|            |-TCK----
>>> |   |         |-TDO----|            |-TDO----
>>> |   |---------|        |            |-TDI----
>>> |       |              |            |
>>> |      TDI             |            |
>>> |       |              |            |
>>> |       |              | MASTER FPGA|
>>> |       |              |            |
>>> |      TDO             |            |
>>> |       |              |            |
>>> |   |---------|-TMS----|            |
>>> |   | FGPA 1  |-TCK----|            |
>>> |   |         |-TDI----|            |
>>> |   |---------|        |------------|
>>>
>>
>> Why do you want the master FPGA to control the others rather than
>> loading them all in one chain?  Connect all TMS and TCK lines in
>> parallel and connect all TDI and TDO in one big daisy chain.  If the
>> slave FPGAs are loaded by the master, where will the data come from?
>>
>> --
>>
>> Rick C
>
> It is reverse engineering, someone did this but i just want reuse board only

The JTAG signals to the master chip, do they connect to general I/Os as 
well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?

You didn't say where you expect the data to come from to program the 
chained slave FPGAs.  Is it supposed to come from the main JTAG port as 
if it was talking to the slave chain?  Or will the master FPGA have a 
separate interface from an MCU or a Flash chip?

What is your overall plan?

-- 

Rick C

Article: 159769
Subject: Re: designing a fpga
From: kristoff <kristoff@skypro.be>
Date: Sun, 26 Feb 2017 14:22:05 +0100
Links: << >>  << T >>  << A >>
Hallo,



On 26-02-17 02:36, thomas.entner99@gmail.com wrote:
> Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
>>> Question, can I conclude from his remark that -if a hardware companie
>>> would start out with designing a fpga- that the problem is more the
>>> "software" side of things than the actual hardware design of the chip.
>>> Or is this conclussion a bit to easy?

>> I'd agree with this.  I'd say the silicon these days is pretty great and the software is the limitation.  It's not for lack of effort, though.  I think most of the resources of an FPGA company go into the software side.
>> I don't quite understand the interest in an open-source FPGA.  I don't believe it would be better than what we are getting commercially.
>> The areas that need the greatest improvement are open to development.  There's nothing stopping somebody from making a better synthesizer.  Convert HDL to structural code.  You can still use this with commercial tools.

> I basically fully agree (except maybe that also P&R might be an interesting topic which is pretty closed). But I want to add some further comments:
> From a technical point, the software is the most difficult. While what Clifford does with YOSYS, etc. sounds extremely impressive (I have not never tested it yet - no time...), it will be next to impossible to find sufficient skilled programmers (in both programming and FPGA design) that contribute for free, IMHO.

Well, my guess is that the key to this is "information", or -to put it 
otherwize- demythifying the technology.

If you look at the codec2 project (the low-bit voice codecĂ . It started 
out as a one-person project of David , but he did a lot of effort to 
really explain the technology and its core concepts. (there are quite a 
few videos from presentation about this on the web).


It is not that this means you end up with hunderd of coders, but it does 
really help to "demythify" a technology, provide a "starting point" for 
who is interesed and get a few people around you.


Also keep in mind that more then 60 % of the code in (e.g.) the 
linux-kernel is actually written by people who are on the payrole of big 
IT companies.




 > From a practical point, however, the hardware is much more difficult, 
simply because it is incredible expensive. Of course you can use a big 
FPGA to simulate the "new" FPGA for a start. But at some point you will 
want to have real chips for the whole project to make sense. And then 
you have a multi-million Euro/dollar project...
 > You have to find a business case for the one how pays this millions 
(if you find someone at all...), and it will most likely be not open source?
 > The next difficult thing about hardware is (beside the patent topic 
others have already mentioned): Either you make a "me too" hardware, 
based on 4-inputs LUTs (the key patents have already expired, I guess) - 
or you invent some improved more or less radical new architecture. This 
would be a big (and interesting task) on it's own, of course... Maybe, 
at the end of Moore's law (?), a clever new architecture could bring a 
real benefit...
 > Business cases that come to my mind are things like:
 > - new FPGA vendor
 > - offer embedded FPGA technology for ASIC suppliers
 > You will need to be able support the customers, etc. and compete 
against the existing players. There is a reason why so many FPGA 
start-ups failed. But this does not mean that it cannot be done, of 
course... Personally I would find it cool to have an Austrian FPGA ;-)


Perhaps the most logical community for this are the people who are now 
involved in the risc-V CPU.


One of the ideas I find interesting what is done by a company called 
"SiFive": they provide help to companies who want to integrate the 
risc-V CPU in their own design. (1)


That's also why their business-model works very well with open-source 
hardware model. Their product is not the CPU itself, nor a customised 
versions of the risc-V, but a service: the process of integrating and 
customising the risc-V for the customer.


In fact, the fact that actually making the hardware is so expensive is 
-their this business model- not necessairy a bad thing. There are 
relative few people are able to "steal" your effort and create CPUs to 
compete with you. This makes donating your work back to the open-source 
community less risky then in the software world.



(1) SiHive also offers the HiFive-1 (a RV32-based dev-kit), designed as 
a way to let people get their hands on a risc-v CPU.



> Regards,
> Thomas
Cheerio! Kr. Bonne.

Article: 159770
Subject: Re: Intel (Altera) announces Cyclone-10
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Sun, 26 Feb 2017 17:53:01 +0100
Links: << >>  << T >>  << A >>
thomas.entner99@gmail.com writes:

>> >> It looks like Intel has learned to count from Microsoft.  The previous
>> >> generation of Cyclone was Cyclone-5.
>
> I think the numbering is the least concern with this "new" family (no
> surprise, as there is already Max 10, Arria 10 and Stratix 10 - with
> similar jumps).
>
> However, it is pretty obvious that:
> Cyclone 10 LP = Cyclone III / IV E
> Cyclone 10 GX = Arria 10 GX
>
> (Such a strategy has long tradition for Altera, look at FLEX10K/ACEX1K, Cyclone III/IV E, MAX II/V...)
>
> It is mainly a marketing / pricing move, which of course is OK if
> there is pricing benefit for the customer. But I always found the way
> it was communicated pretty misleading... (Very dishonest. Fake news.)
> (I had no contact to an Altera/Intel FAE recently - not sure how they
> communicate this.)
>
> However, especially Arria 10 GX for Cyclone pricing could be a real deal. (Great deal. So wonderful.)

Do you have any information that the Cyclone 10 GX will actually replace
the Arria 10 GX?

I would expect the Cyclone 10 GX to replace the Cyclone V GX. The
Cyclone 10 GX transceivers are slower than the current Arria 10
transceivers according to link posted earlier.

I think the 10 was introduced as this was the 10th generation FPGA from
Altera. I can remember LSI Logic did a similar name change with their
ASIC's when the G10 family was introduced.


//Petter

-- 
.sig removed by request. 

Article: 159771
Subject: Re: Intel (Altera) announces Cyclone-10
From: thomas.entner99@gmail.com
Date: Sun, 26 Feb 2017 09:42:10 -0800 (PST)
Links: << >>  << T >>  << A >>
> Do you have any information that the Cyclone 10 GX will actually replace
> the Arria 10 GX?
>=20
> I would expect the Cyclone 10 GX to replace the Cyclone V GX.=20

Please note that I do not "have information", I just look at the datasheet =
and outline the obvious...

I do not think that the new family will replace anything, all the families =
will coexist for quite some time. Of course new projects will mostly use ne=
wer families... (I think one of the reasons for the new family is to allow =
Altera to make more aggressive pricing for new projects and keep the pricin=
g high for the "old" families, esp. Arria 10, that are already used in prod=
ucts)

It would still be interesting to hear if there is maybe some subtle differe=
nce, e.g. in power consumption. Maybe someone has already access to an powe=
r estimator of Cyclone 10 GX to compare with Arria 10 (esp. the smallest pa=
rts of Cyclone 10 GX)?

Regards,

Thomas

Article: 159772
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Sun, 26 Feb 2017 14:32:23 -0500
Links: << >>  << T >>  << A >>
On 2/25/2017 8:36 PM, thomas.entner99@gmail.com wrote:
> Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
>>> Question, can I conclude from his remark that -if a hardware
>>> companie would start out with designing a fpga- that the problem
>>> is more the "software" side of things than the actual hardware
>>> design of the chip.
>>>
>>>
>>> Or is this conclussion a bit to easy?
>>
>> I'd agree with this.  I'd say the silicon these days is pretty
>> great and the software is the limitation.  It's not for lack of
>> effort, though.  I think most of the resources of an FPGA company
>> go into the software side.
>>
>> I don't quite understand the interest in an open-source FPGA.  I
>> don't believe it would be better than what we are getting
>> commercially.
>>
>> The areas that need the greatest improvement are open to
>> development.  There's nothing stopping somebody from making a
>> better synthesizer.  Convert HDL to structural code.  You can still
>> use this with commercial tools.
>
> I basically fully agree (except maybe that also P&R might be an
> interesting topic which is pretty closed). But I want to add some
> further comments:
>
> From a technical point, the software is the most difficult. While
> what Clifford does with YOSYS, etc. sounds extremely impressive (I
> have not never tested it yet - no time...), it will be next to
> impossible to find sufficient skilled programmers (in both
> programming and FPGA design) that contribute for free, IMHO.
>
> From a practical point, however, the hardware is much more difficult,
> simply because it is incredible expensive. Of course you can use a
> big FPGA to simulate the "new" FPGA for a start. But at some point
> you will want to have real chips for the whole project to make sense.
> And then you have a multi-million Euro/dollar project...
>
> You have to find a business case for the one how pays this millions
> (if you find someone at all...), and it will most likely be not open
> source?
>
> The next difficult thing about hardware is (beside the patent topic
> others have already mentioned): Either you make a "me too" hardware,
> based on 4-inputs LUTs (the key patents have already expired, I
> guess) - or you invent some improved more or less radical new
> architecture. This would be a big (and interesting task) on it's own,
> of course... Maybe, at the end of Moore's law (?), a clever new
> architecture could bring a real benefit...
>
> Business cases that come to my mind are things like: - new FPGA
> vendor - offer embedded FPGA technology for ASIC suppliers
>
> You will need to be able support the customers, etc. and compete
> against the existing players. There is a reason why so many FPGA
> start-ups failed. But this does not mean that it cannot be done, of
> course... Personally I would find it cool to have an Austrian FPGA
> ;-)

There are lots of great chips out there and as has been done for a few 
Lattice parts, they can be reverse engineered to get past the bitstream 
issue.

What I would like to see is a different approach to the design software. 
  In the early days FPGA place and routing was done with a large amount 
of hand work.  As technology progressed the tools did better and better 
designs.  As designs got larger and larger it became essential that the 
software would take over from the designer and essentially handle all 
aspects of place and route.

I tend to work on smaller projects where it would be practical for the 
designer to be more intimately involved in the placement and routing... 
well, the placement anyway.  Routing is no fun!  I'd like to see tools 
that allow construction of logical blocks using the device provided 
primitives in a hierarchical fashion that supports easy placement 
control.  Once a good placement is found, auto-routing is made much 
easier.  Yes, this can be done in HDL in theory, but it is not so easy 
and very verbose.

-- 

Rick C

Article: 159773
Subject: Re: designing a fpga
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 27 Feb 2017 09:13:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, February 24, 2017 at 2:43:45 AM UTC-5, kristoff wrote:
> ... Wolf Clifford ... opensource fpga flow at ccc ...
>
> Question, can I conclude from his remark that -if a hardware companie 
> would start out with designing a fpga- that the problem is more the 
> "software" side of things than the actual hardware design of the chip.
> 
> Or is this conclussion a bit to easy?

Kristoff, I am so happy that you started this thread.  It has given me
much to think about.

Thank you,
Rick C. Hodgin

Article: 159774
Subject: Re: designing a fpga
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 27 Feb 2017 13:49:04 -0600
Links: << >>  << T >>  << A >>
rickman wrote:

> On 2/24/2017 11:30 PM, Jon Elson wrote:
 How about designing your own ring oscillator?
> 
> I'm not sure how to even do that in an HDL.
Yes, I didn't do it, but we have a design that has a 33 MHz ring oscillator 
that is some piece of IP.  I never looked to see how it was coded.  This is 
on a Spartan 3AN part.


> I suppose you can have a
> second input to each inverter and set bits in a register to enable it.
> But it would still have an combinatorial feedback path which would flag
> an error in the timing analyzer unless you except that path.  Where do
> you see the problem?
> 
Just that I would expect it to give the simulator indigestion!

I started out with CPLDs, doing schematic entry.  Then, I moved to FPGAs, 
and schematic entry worked, but led to a lot of maintenance hassles.  I 
finally saw the light, and learned VHDL.

Jon



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