Which Altera to buy?

[rickman]

On 12/2/2014 2:40 PM, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
Nice info. You might consider using a log scale for the pricing axis.
That would help spread out the low end rather than having all that data
bunched into the corner. Maybe even log the size axis too.

I did try, but it wasn't usable in the limited space I had for the paper.
Here's a larger loglog version:
http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf

There you go! Great job. Interesting how the members of a family are
more evenly spaced on a log scale for size.

BTW, where did you get your pricing data? One thing I have learned
about FPGA pricing is that list price means nothing if you are buying
any real quantity. To get a design win, especially in a new family,
they will bid very aggressively.

--

Rick

 

[Rick C. Hodgin]

On Tuesday, December 2, 2014 10:10:04 PM UTC-5, rickman wrote:

On 12/2/2014 9:14 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 7:51:39 PM UTC-5, rickman wrote:
On 12/2/2014 6:21 PM, Rick C. Hodgin wrote:
Because it would work in wholly replicable logic within the FPGA,
requiring nothing other than connecting up pins.
You mean like SPI, I2C, async serial, etc, etc, etc...

I don't know of any of those other than by their names used in
various technical specs I've read over time. If they work like
the one I'm proposing, then what's the big deal? The protocol
I would define would include a 16-bit word for the target sub-
unit, a 16-bit word for the payload length, and then the payload.

I'm not sure what you are proposing. Sounds more like you are
describing a software protocol. If you want to do your own thing
fine, but there are times when compatibility can be useful and
reinventing the wheel is seldom an advantage.

I don't understand how what I'm doing is reinventing the wheel if I
am merely hooking up a few pins and using 0s and 1s in data interchange
on a fixed clock. It sounds like I'm applying the most fundamental
concepts of data interchange available in FPGA programming.

From my point of view, employing some proprietary communications
hardware and/or its software protocols of peculiar format, ones which
may even require the data I would pass from one unit to another be re-
formatted in some protocol-required way for transmission, and then de-
coded upon receipt, seems be the more undesirable path.

FWIW, I'm talking about slow device on-motherboard communications here,
and potentially some remote debugging communication across multi-CPUs
through a single interface.
You mean like SPI, I2C, async serial, etc, etc, etc...

One *big* advantage to using something standard is that other devices
can talk to it, not just your designs. If you get into a tough spot you
can even get low cost debuggers for any of these other protocols.

I am writing my own debugger.

I'm not talking about a software debugger. I'm talking about a debugger
for your interface. Call it a scope then.

I am writing a debugger which will cover these things. Whatever is
going on inside the FPGA will be able to be ported out through the
Ethernet into the debugger based on various register settings. I
will write the debugger to understand the hardware it relates to,
providing even graphical images of the data communication.

From what I have seen, efforts to get the Ethernet protocol up and
running should be simple and straight-forward enough. We'll see
though. I'm prepared to spend as much time as it takes, posting my
code so people can help me if I'm doing something incorrectly. I
can also always fall back on the default connections which exist on
the Altera dev board until I get it debugged. Once it's written,
however, it will be available for all from that point forward. Any
port of the verilog code to other devices should be doable through
that TI chip.

For RS232, the FPGA pins go to level converters to convert to the
appropriate voltages, but all the logic (UART) is in the FPGA.
I am absolutely loving this project so far. I think it's my all-time
favorite.

I assume it is all just for fun?

No. It is to become the foundation of a hardware and software stack
I am creating that has roots in the 80386 design, but has been modified
to be simpler, and has been extended out to 40-bits.

To what end?

I am a Christian. I desire to create a hardware and software stack
from the ground up, one focused upon an offering of sharing and love,
rather than of profits, sales goals, and proprietary hardware locks.

I would also like to create the tools to produce the semiconductor
products as well, which I plan to do after I get my CPU designed.
I will design the layout and routing tools, and move toward
manufacturing.

The fact that it is going to be open source doesn't remove it from the
world of markets. What need is this satisfying? Clearly you expect
others to use it. Have you made any efforts to see what others want
from such devices?

It is not open source. It's in the Public Domain. I have created a
license model which indicates that our responsibilities tie back to God,
and not to our legal system, that my wishes are that the software
remains open, and that, just as God gave us this world and instructed
us on how to use it, allowing us to choose for ourselves, and warning
us of the consequences if we use it in a manner contrary to His
instruction, and how we are all accountable unto Him for how we use it,
and how we treat one another, and for everything involved with our
lives, so are we also accountable unto Him for how we honor other
people's wishes with regards to offerings which stem from Him in the
first place.

Jesus Christ gave me the knowledge and skills I possess. I did not
garner them on my own. I was endowed at birth with whatever abilities
I possess. And the opportunities I've had in my life, may of which I've
flatly squandered due to my own ignorance and stupidity, still all of
these were a gift from Him unto me. And I now acknowledge that, and I
cite that explicitly in my license.

When people take my offering and use it for other ends, they are doing
it to Him, and not just me, and, per His instruction (Revelation 22:10-12),
I will let Him take full account of all such movements.

What if you build it and nobody comes because you built something no
one wants?

It is a common mis-perception that Christians operate alone in this
world. We are not alone. God is with us, living inside of our heart,
our minds, continually. This is true of all born again Christians.
And all such efforts given over unto God from that inner place of the
changed heart, these are all known unto God, and it is He who then
moves in this world, moving us to and fro, moving others to and fro,
drawing us from within toward His ends as per His plans and purposes
(John 3:3,6-8).

Yet, if nobody comes because I built something no one wants, then I
will, at the end of my time upon this Earth, stand before God and say,
"I spent the last N years of my life doing everything I could for You,
by name, asking for help, finding nobody to assist me, nobody to use
the offerings I created using the skills and talents You gave me, yet
I persisted because from within my heart I was doing it for You."

It is enough to live this way for the Lord.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:

On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote:

On 12/2/2014 11:10 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

So you have a requirement for 1 TB of address space. What are your
other requirements, but more importantly, what is driving those
requirements?

I have no particular hardware requirements except that from the ground
up it be a love offering unto the Lord. I have a background in x86
space from before I was a Christian, and I'm taking that knowledge
forward, coupled with the things I've wanted or wished for in x86
space throughout my career.

Ultimately I desire to have a CPU, all motherboard resources, any
BIOS or firmware, the kernel, operating system, and all end-user
software, be created from the LibSF offerings, with all of it being
given unto the world without restriction, as a foundation or base
upon which to build.

I would like to be able to work with 14nm process technologies, and
create CPUs that would outperform anything that exists ... but it's
not the place the Lord has me. I am Rick C. Hodgin from Indiana.
No riches. No skills in such things. I am waiting for others to
come forward and offer up those things which they have in a similar
way so that we can walk together, arm in arm, for the Lord. I
believe very strongly that we could give unto the world as good or
better as anything else that's out there because we'd be serving
the Lord, listening to Him, doing what we do for Him, not taking
shortcuts, not being pressed for quarterly fiscal deadlines, but
rather being able to do it right because it's our best we desire
to give.

It's up to Him though. I've been working on this project for over
28 months. I haven't found anyone to help me yet, though several
people have been interested at various times, none of them had the
necessary C/C++ coding skills to contribute. I've contacted
Christian universities, posted on forums, etc. But, I am hopeful.


Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, December 3, 2014 12:16:26 AM UTC-5, rickman wrote:

On 12/2/2014 11:27 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote:
On 12/2/2014 11:10 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

So you have a requirement for 1 TB of address space. What are your
other requirements, but more importantly, what is driving those
requirements?

I have no particular hardware requirements except that from the ground
up it be a love offering unto the Lord. I have a background in x86
space from before I was a Christian, and I'm taking that knowledge
forward, coupled with the things I've wanted or wished for in x86
space throughout my career.

Ultimately I desire to have a CPU, all motherboard resources, any
BIOS or firmware, the kernel, operating system, and all end-user
software, be created from the LibSF offerings, with all of it being
given unto the world without restriction, as a foundation or base
upon which to build.

I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack
fingerprinting library" which I found on the web.

It's not important.

I would like to be able to work with 14nm process technologies, and
create CPUs that would outperform anything that exists ... but it's
not the place the Lord has me. I am Rick C. Hodgin from Indiana.
No riches. No skills in such things. I am waiting for others to
come forward and offer up those things which they have in a similar
way so that we can walk together, arm in arm, for the Lord. I
believe very strongly that we could give unto the world as good or
better as anything else that's out there because we'd be serving
the Lord, listening to Him, doing what we do for Him, not taking
shortcuts, not being pressed for quarterly fiscal deadlines, but
rather being able to do it right because it's our best we desire
to give.

That's the part I don't understand. Here you say you are, "listening to
Him", but how does that turn into defining a CPU? Why/how is the CPU you
are designing any better for "Him" or anyone else than any other CPU you
might design?

It relates back to the nature of the offer, as it comes from the
inner drive of love and the offering of the things we posses given
back unto Him by our heart's desire.

It's up to Him though. I've been working on this project for over
28 months. I haven't found anyone to help me yet, though several
people have been interested at various times, none of them had the
necessary C/C++ coding skills to contribute. I've contacted
Christian universities, posted on forums, etc. But, I am hopeful.


Maybe if you find a way to express the motivation and the guiding
principles so that others can understand.

They're there.

Best regards,
Rick C. Hodgin

 

[rickman]

On 12/2/2014 6:21 PM, Rick C. Hodgin wrote:

On Tuesday, December 2, 2014 5:20:17 PM UTC-5, rickman wrote:
I purchased a TI PHY chip today (DP83848C 10/100 model) in a pin package
that I believe will allow direct connection to the Altera dev board. I
downloaded the protocol specs and it was very straight-forward. I found
a better solution earlier from Silicon Labs, but I couldn't find an
inexpensive connection board that didn't require something like solder
masks ... so I went with TI's already-together product.

Why not just use an integrated PHY/MAC and save the trouble of rolling
your own? How big is the device you will need?

The product I bought:
http://www.amazon.com/gp/product/B00KM6VNBC/ref=oh_aui_detailpage_o00_s00

Yes, this seems to have a PHY by TI, DP83848. The interface lists MII,
RMII and SNI.

For point-to-point inter-LibSF-device communication I think I'll simply
invent Libernet, a simple protocol using five pins (tx-clk, tx, rx-clk,
rx, and gnd) and make the communication protocol as simple as possible.

I like the idea of Manchester coding, however, and may consider using
that as well to keep pin count down at the expense of some logic on
the sending and receiving end.

Please don't roll your own serial interface. You will forever regret it
I think. Why add to the huge number of existing interfaces when nearly
every need has already been met by one or the other?

Because it would work in wholly replicable logic within the FPGA,
requiring nothing other than connecting up pins.

You mean like SPI, I2C, async serial, etc, etc, etc...

FWIW, I'm talking about slow device on-motherboard communications here,
and potentially some remote debugging communication across multi-CPUs
through a single interface.

You mean like SPI, I2C, async serial, etc, etc, etc...

One *big* advantage to using something standard is that other devices
can talk to it, not just your designs. If you get into a tough spot you
can even get low cost debuggers for any of these other protocols.

For RS232, the FPGA pins go to level converters to convert to the
appropriate voltages, but all the logic (UART) is in the FPGA.
I am absolutely loving this project so far. I think it's my all-time
favorite.

I assume it is all just for fun?

No. It is to become the foundation of a hardware and software stack
I am creating that has roots in the 80386 design, but has been modified
to be simpler, and has been extended out to 40-bits.

To what end?

--

Rick

 

[rickman]

On 12/2/2014 9:14 PM, Rick C. Hodgin wrote:

On Tuesday, December 2, 2014 7:51:39 PM UTC-5, rickman wrote:
On 12/2/2014 6:21 PM, Rick C. Hodgin wrote:
Because it would work in wholly replicable logic within the FPGA,
requiring nothing other than connecting up pins.
You mean like SPI, I2C, async serial, etc, etc, etc...

I don't know of any of those other than by their names used in
various technical specs I've read over time. If they work like
the one I'm proposing, then what's the big deal? The protocol
I would define would include a 16-bit word for the target sub-
unit, a 16-bit word for the payload length, and then the payload.

I'm not sure what you are proposing. Sounds more like you are
describing a software protocol. If you want to do your own thing fine,
but there are times when compatibility can be useful and reinventing the
wheel is seldom an advantage.

FWIW, I'm talking about slow device on-motherboard communications here,
and potentially some remote debugging communication across multi-CPUs
through a single interface.

You mean like SPI, I2C, async serial, etc, etc, etc...

One *big* advantage to using something standard is that other devices
can talk to it, not just your designs. If you get into a tough spot you
can even get low cost debuggers for any of these other protocols.

I am writing my own debugger.

I'm not talking about a software debugger. I'm talking about a debugger
for your interface. Call it a scope then.

For RS232, the FPGA pins go to level converters to convert to the
appropriate voltages, but all the logic (UART) is in the FPGA.
I am absolutely loving this project so far. I think it's my all-time
favorite.

I assume it is all just for fun?

No. It is to become the foundation of a hardware and software stack
I am creating that has roots in the 80386 design, but has been modified
to be simpler, and has been extended out to 40-bits.

To what end?

I am a Christian. I desire to create a hardware and software stack
from the ground up, one focused upon an offering of sharing and love,
rather than of profits, sales goals, and proprietary hardware locks.

I would also like to create the tools to produce the semiconductor
products as well, which I plan to do after I get my CPU designed.
I will design the layout and routing tools, and move toward
manufacturing.

The fact that it is going to be open source doesn't remove it from the
world of markets. What need is this satisfying? Clearly you expect
others to use it. Have you made any efforts to see what others want
from such devices?

What if you build it and nobody comes because you built something no one
wants?

--

Rick

 

[rickman]

On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:

It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this processor?
For example, why 40 bits? Isn't that going to make some features of
the 386 difficult or impossible to implement?

--

Rick

 

[rickman]

On 12/2/2014 11:10 PM, Rick C. Hodgin wrote:

On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

So you have a requirement for 1 TB of address space. What are your
other requirements, but more importantly, what is driving those
requirements?

--

Rick

 

[rickman]

On 12/2/2014 11:27 PM, Rick C. Hodgin wrote:

On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote:
On 12/2/2014 11:10 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

So you have a requirement for 1 TB of address space. What are your
other requirements, but more importantly, what is driving those
requirements?

I have no particular hardware requirements except that from the ground
up it be a love offering unto the Lord. I have a background in x86
space from before I was a Christian, and I'm taking that knowledge
forward, coupled with the things I've wanted or wished for in x86
space throughout my career.

Ultimately I desire to have a CPU, all motherboard resources, any
BIOS or firmware, the kernel, operating system, and all end-user
software, be created from the LibSF offerings, with all of it being
given unto the world without restriction, as a foundation or base
upon which to build.

I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack
fingerprinting library" which I found on the web.

I would like to be able to work with 14nm process technologies, and
create CPUs that would outperform anything that exists ... but it's
not the place the Lord has me. I am Rick C. Hodgin from Indiana.
No riches. No skills in such things. I am waiting for others to
come forward and offer up those things which they have in a similar
way so that we can walk together, arm in arm, for the Lord. I
believe very strongly that we could give unto the world as good or
better as anything else that's out there because we'd be serving
the Lord, listening to Him, doing what we do for Him, not taking
shortcuts, not being pressed for quarterly fiscal deadlines, but
rather being able to do it right because it's our best we desire
to give.

That's the part I don't understand. Here you say you are, "listening to
Him", but how does that turn into defining a CPU? Why/how is the CPU you
are designing any better for "Him" or anyone else than any other CPU you
might design?

It's up to Him though. I've been working on this project for over
28 months. I haven't found anyone to help me yet, though several
people have been interested at various times, none of them had the
necessary C/C++ coding skills to contribute. I've contacted
Christian universities, posted on forums, etc. But, I am hopeful.

Maybe if you find a way to express the motivation and the guiding
principles so that others can understand.

--

Rick

 

[Rick C. Hodgin]

rickman wrote:

Rick C. Hodgin wrote:
rickman wrote:
Maybe if you find a way to express the
motivation and the guiding principles so
that others can understand.
They're there.

When you can express them in ways most
people can understand and appreciate I
expect you will find a few people who will
join you.

The people who come to this project will do so
from within. It will be the same drive which
moves me, which moves them -- an indwelling
of His Holy Spirit, and a change, a desire to do
the things we do, in whatever industry we're in,
for Him.

Some (most) will never be able to understand
the drive there, nor see the value/gain in giving
and sharing knowledge, sacrificing intellectual
property rights so our fellow man might be able
to create a better thing upon our prior work,
etc.

It is the nature of the division between born-
again, and not born-again. It is why we need
Jesus Christ, for without a faith in Him, a pursuit
of Truth in our life, the flesh-based blindness
prevents us from moving as we should.

Jesus changes everything about a person's life.
He fundamentally rewires everything about a
person, from the inner thoughts to the inner
drives. He is pervasive, and complete, and He
opens our eyes to see the things we were blind
to before.

I urge you to seek Him, Rick. He will forgive you
too, and change your life. Forever.

Best regards,
Rick C. Hodgin

 

[rickman]

On 12/3/2014 12:45 AM, Rick C. Hodgin wrote:

On Wednesday, December 3, 2014 12:16:26 AM UTC-5, rickman wrote:
On 12/2/2014 11:27 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote:
On 12/2/2014 11:10 PM, Rick C. Hodgin wrote:
On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote:
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote:
It is enough to live this way for the Lord.

So what is guiding your technical decisions in designing this
processor?
For example, why 40 bits? Isn't that going to make some features
of the 386 difficult or impossible to implement?

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png

40-bits takes you to 1 Terabyte. If more is needed later, the
LibSF 386-x48 can be created.

So you have a requirement for 1 TB of address space. What are your
other requirements, but more importantly, what is driving those
requirements?

I have no particular hardware requirements except that from the ground
up it be a love offering unto the Lord. I have a background in x86
space from before I was a Christian, and I'm taking that knowledge
forward, coupled with the things I've wanted or wished for in x86
space throughout my career.

Ultimately I desire to have a CPU, all motherboard resources, any
BIOS or firmware, the kernel, operating system, and all end-user
software, be created from the LibSF offerings, with all of it being
given unto the world without restriction, as a foundation or base
upon which to build.

I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack
fingerprinting library" which I found on the web.

It's not important.

I would like to be able to work with 14nm process technologies, and
create CPUs that would outperform anything that exists ... but it's
not the place the Lord has me. I am Rick C. Hodgin from Indiana.
No riches. No skills in such things. I am waiting for others to
come forward and offer up those things which they have in a similar
way so that we can walk together, arm in arm, for the Lord. I
believe very strongly that we could give unto the world as good or
better as anything else that's out there because we'd be serving
the Lord, listening to Him, doing what we do for Him, not taking
shortcuts, not being pressed for quarterly fiscal deadlines, but
rather being able to do it right because it's our best we desire
to give.

That's the part I don't understand. Here you say you are, "listening to
Him", but how does that turn into defining a CPU? Why/how is the CPU you
are designing any better for "Him" or anyone else than any other CPU you
might design?

It relates back to the nature of the offer, as it comes from the
inner drive of love and the offering of the things we posses given
back unto Him by our heart's desire.

Really? The technical decisions arise from a drive of love? That's
hard to put in a requirements document.

It's up to Him though. I've been working on this project for over
28 months. I haven't found anyone to help me yet, though several
people have been interested at various times, none of them had the
necessary C/C++ coding skills to contribute. I've contacted
Christian universities, posted on forums, etc. But, I am hopeful.


Maybe if you find a way to express the motivation and the guiding
principles so that others can understand.

They're there.

When you can express them in ways most people can understand and
appreciate I expect you will find a few people who will join you.

--

Rick

 

[Rick C. Hodgin]

I have had long-term goals:

(1) Visual FreePro and its compiler framework
(2) Exodus 32-bit x86-based operating system
(3) Armodus 32-bit ARM-based OS.
(4) Exodus 64-bit.
(5) Armodus 64-bit

And various other related system and user apps.

I have only discovered in the last month that I
have some natural understanding of hardware.
Until this Oppie-1 project, I had always viewed
hardware as some distant and nebulous thing.
But now that I see I have this knowledge and
ability, much to my surprise I might add, I am
moving in this way.

It's absolutely floored me to be honest. When I
began to learn Verilog, and write things, and it
all made sense, I literally walked around my
house in disbelief saying out loud, "No way!"

And in the weeks since I've looled at how the
various hardware interconnects, and it's like this
veil has been lifted and I can see the hardware
ends.

The path before me is now a combined path:

(1) LibSF 386-x40 comprised of
(2) Exodus OS,
(3) Visual FreePro, and its general IDE supporting a C-like compiler, and
(4) Other user apps

Best regards,
Ricl C. Hodgin

 

[Rick C. Hodgin]

You can read my original goals here:

http://www.visual-freepro.org/forum/viewtopic.php?f=3&t=14

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

David,

Jesus loves you. And I love you. Seek Him.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

David,

You are always writing posts to guide me in my
endeavors. It is a good sentiment, and I wanted
to do likewise.

Your skills and knowledge are a great asset. Use
them wisely.

Best regards,
Rick C. Hodgin

 

[David Brown]

On 03/12/14 01:26, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I can't seem to find it now, but someone recently posted a link to
price/LUT vs size data in graph form. It gets a bit crowded at the
bottom end, but appears to show there is no real price difference
between the two brands. The data does include a very small number of
other devices than X and A, but not enough to be useful.

Graphs again:
http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf (page 2)
http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf

I had data for ECP3 and Igloo 2. Most of the others that Digikey listed are
either very small (<20K LEs), missing LE data in their table, or legacy
products (APEX, XC4000, etc). There wasn't enough data to plot anything
reasonable from those. A graph of sub-20K devices would be interesting, but
it's a very different market.

In fact it is interesting that the prices get very crowded at the low
end jamming up the graph. I suggested that he present the data with a
logarithmic Y axis or even in log-log form. Clearly competitive market
forces at work.

One of the interesting things to note is the pricing margin between budget
and premium ranges: you pay 4-6x more per LE in a 'premium' family than in a
budget range. So if you can build a system with multiple FPGAs (and we
described a way to do that in the paper, which fits some applications better
than others) then it can be economic to use smaller budget FPGAs rather than
buy the premium FPGA.

The alternative theory is that people buy budget FPGAs from Digikey, and
buying premium devices requires a long chat with a salesman, so the Digikey
list prices for those are mostly fiction that nobody pays. However the same
trend seems to apply across all vendors.

Theo

There is also the point that the chips, especially the premium ones,
include more than just logic elements - somewhere you will also be
paying for hard core processors, fast transceivers, multi-port RAM, more
I/O, etc. And different architectures have different ideas about what a
logic element actually /is/. These sorts of things mean that a
price-per-LE is only a simplistic comparison - although it is probably
the best single figure that could be used here.

But I expect that the main reason for the price margin is economy of
scale - far more low-end FPGAs are produced than high-end ones, making
production and testing costs very different.

 

[David Brown]

On 02/12/14 20:56, glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:

For RS232, the FPGA pins go to level converters to convert to the
appropriate voltages, but all the logic (UART) is in the FPGA.

I would recommend you use an FTDI USB chip instead of RS232 - it is
easier, /much/ faster, and can connect to modern PC's that seldom have
RS232 ports. An FTDI 4232H chip will give you up to 4 UARTs (or 2 UARTs
and 2 SPI/I2C/JTAG) with something like 12 MBaud transmission rates.

 

[rickman]

On 12/3/2014 4:21 AM, David Brown wrote:

On 03/12/14 01:26, Theo Markettos wrote:
rickman <gnuarm@gmail.com> wrote:
I can't seem to find it now, but someone recently posted a link to
price/LUT vs size data in graph form. It gets a bit crowded at the
bottom end, but appears to show there is no real price difference
between the two brands. The data does include a very small number of
other devices than X and A, but not enough to be useful.

Graphs again:
http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf (page 2)
http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf

I had data for ECP3 and Igloo 2. Most of the others that Digikey listed are
either very small (<20K LEs), missing LE data in their table, or legacy
products (APEX, XC4000, etc). There wasn't enough data to plot anything
reasonable from those. A graph of sub-20K devices would be interesting, but
it's a very different market.

In fact it is interesting that the prices get very crowded at the low
end jamming up the graph. I suggested that he present the data with a
logarithmic Y axis or even in log-log form. Clearly competitive market
forces at work.

One of the interesting things to note is the pricing margin between budget
and premium ranges: you pay 4-6x more per LE in a 'premium' family than in a
budget range. So if you can build a system with multiple FPGAs (and we
described a way to do that in the paper, which fits some applications better
than others) then it can be economic to use smaller budget FPGAs rather than
buy the premium FPGA.

The alternative theory is that people buy budget FPGAs from Digikey, and
buying premium devices requires a long chat with a salesman, so the Digikey
list prices for those are mostly fiction that nobody pays. However the same
trend seems to apply across all vendors.

Theo


There is also the point that the chips, especially the premium ones,
include more than just logic elements - somewhere you will also be
paying for hard core processors, fast transceivers, multi-port RAM, more
I/O, etc. And different architectures have different ideas about what a
logic element actually /is/. These sorts of things mean that a
price-per-LE is only a simplistic comparison - although it is probably
the best single figure that could be used here.

But I expect that the main reason for the price margin is economy of
scale - far more low-end FPGAs are produced than high-end ones, making
production and testing costs very different.

Don't kid yourself. Yes, there will be some additional cost for I/O and
the hard cores and even the more advanced LUT designs. I can assure you
that "economy of scale" is not really the issue for any but the biggest
devices. But that is largely in the noise when looking at a 60x range
of cost per LUT. The high end is charging what the market will bear
just as is true in nearly any market with constantly renewed products.

--

Rick

 

[rickman]

On 12/3/2014 6:00 AM, Rick C. Hodgin wrote:

rickman wrote:
Rick C. Hodgin wrote:
rickman wrote:
Maybe if you find a way to express the
motivation and the guiding principles so
that others can understand.
They're there.

When you can express them in ways most
people can understand and appreciate I
expect you will find a few people who will
join you.

The people who come to this project will do so
from within. It will be the same drive which
moves me, which moves them -- an indwelling
of His Holy Spirit, and a change, a desire to do
the things we do, in whatever industry we're in,
for Him.

Some (most) will never be able to understand
the drive there, nor see the value/gain in giving
and sharing knowledge, sacrificing intellectual
property rights so our fellow man might be able
to create a better thing upon our prior work,
etc.

I'm not questioning the drive. I'm asking how this effort is being led.
I don't see where the decisions are coming from. For a project like
this to succeed there has to be a basis from which the technical
decisions are made. If it is all by the seat of your pants, that's
fine, but it will be hard to find others who are willing to follow your
lead.

I think I understand this better now. Thanks.

--

Rick