Which Altera to buy?

[rick.c...@gmail.com]

Greetings. I am new to FPGA programming. I am
seeking to create a 40-bit 80386-like CPU core
with a 32-bit and 64-bit FPU with 16 registers,
a 128-bit four- and two-way 32-bit and 64-bit
vector FPU engine with 16 registers, 60
additional general purpose integer registers,
and a six stage execution pipeline.

I am wondering if somebody can guide me into
which Altera product I should use for this CPU design? Thank you in advance.

Best regards,
Rick C. Hodgin

[glen herrmannsfeldt]

rick.c...@gmail.com wrote:

> Greetings. I am new to FPGA programming. I am
> seeking to create a 40-bit 80386-like CPU core
> with a 32-bit and 64-bit FPU with 16 registers,
> a 128-bit four- and two-way 32-bit and 64-bit
> vector FPU engine with 16 registers, 60
> additional general purpose integer registers,
> and a six stage execution pipeline.

> I am wondering if somebody can guide me into
> which Altera product I should use for this CPU design?

Most likely a big one.

If you simplify the system somewhat, maybe only a medium sized one.

-- glen

[rickman]

There is some interesting software they provide for working with Altera
FPGAs called Quartus. It will let you synthesize your designs and
measure the size. Then you can tell what size part it will fit. No
guesswork required. :)

The same package has a simulator to allow you to do a lot of testing
without ever buying a chip or board.

So design your chip, do *lots* of simulating to verify that all the
instructions work. Optimize your architecture and then, only then
consider which chip you need to buy.

You might want to look for one that has hardware floating point support
since you plan to implement floating point. But the size words they
implement may not be the size you want so you may need to do that in the
fabric anyway.

--

Rick

[Theo Markettos]

rick.c...@gmail.com wrote:
> Greetings. I am new to FPGA programming. I am
> seeking to create a 40-bit 80386-like CPU core
> with a 32-bit and 64-bit FPU with 16 registers,
> a 128-bit four- and two-way 32-bit and 64-bit
> vector FPU engine with 16 registers, 60
> additional general purpose integer registers,
> and a six stage execution pipeline.

For a point of comparison, we have a 64-bit MIPS-like CPU core, with MMU,
L1/L2 cache, 32-bit floating point support, capability unit (32x 256-bit
registers), and a 256 bit datapath to DDR2 memory, and it runs at 100MHz in
about 80% of a Stratix IV GX230 (230K LEs). Picture and numbers on page 10
here (the Stratix IV doesn't have hard floating point):
http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201406-isca2014-cheri.pdf

This is not particularly optimised for size (or speed), and when you put
more things on the FPGA the area usage for the CPU shrinks as the tools work
harder. We're trying to make it fit in a Cyclone V SoC part
(5CSXFC6D6F31C6N) but haven't yet trimmed it down sufficiently.

The 10 family apparently supports hard floating point: the Stratix 10 is not
available yet but the Arria 10 might be worth a look.

The Arria family is also worth looking at from a cost per LE point of view:
according to my graph on page 2 here:
http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf
it works out somewhat cheaper LUT-for-LUT than the Stratix parts.

Theo

[rickman]

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.

--

Rick

[rick.c...@gmail.com]

Thank you for the replies and info.

I will be designing my CPU in several stages. I
have the first stage designed but not debugged.
Am working on that this week (Lord willing).

Would it be preferable to design and test each
in Quartus-II only? What about DRAM controllers?
And Ethernet? I plan on using Ethernet for remote
debugging during development and testing. And
do I want a dev board with VGA out to make it
easier? Or should I pass everything through the
Ethernet port?

Thank you in advance for your assistance. It is
greatly appreciated. :-)

[rickman]

On 12/2/2014 7:58 AM, rick.c...@gmail.com wrote:
> Thank you for the replies and info.
>
> I will be designing my CPU in several stages. I
> have the first stage designed but not debugged.
> Am working on that this week (Lord willing).
>
> Would it be preferable to design and test each
> in Quartus-II only? What about DRAM controllers?
> And Ethernet? I plan on using Ethernet for remote
> debugging during development and testing. And
> do I want a dev board with VGA out to make it
> easier? Or should I pass everything through the
> Ethernet port?

I'm not sure what would be easier. I've never worked with Ethernet in
an FPGA before. I would think you could get a VGA interface working
faster than an Ethernet interface will all the software required. Are
you planning to run Linux on it or will you be coding to the bare metal
without an OS? Will your Ethernet interface be a full custom or are you
going to use an Ethernet module that provides a serial link to your CPU?

--

Rick

[rick.c...@gmail.com]

I found a simple Ethernet controller on fpga4fun:

http://www.fpga4fun.com/10BASE-T.html

I plan on creating a simple buffer which receives internal pipe stage
information at each CPU clock, and then transmits that data back out in
real-time to some a port being monitored by my debugger. This will allow
me to then constantly monitor the machine state. I can also then encode
external source level single-step debugging, assembly tools, make even
program changes in real-time, etc., to complete the entire toolset.

I developed my own kernel and primitive OS back in the late 90s, early
00s. I will be using a modified version of that as the ISA I'm using
is somewhat different than the actual 80386 ISA in (except in
compatibility mode, which I will probably add last).

I'm thinking I would also like to figure out and test timing on a fixed
SVGA video mode for a 1920x1080 signal at 60 Hz, and just hard-code that
video mode and use it for everything the machine does until I can later
add other modes. And the same for a DRAM controller so I can have that
consistent and normal access to memory, Ethernet, and VGA throughout all
of my development.

[Rick C. Hodgin]

I've since given this some additional thought and have decided I'll
transmit everything over Ethernet. In this way I can create several
virtual screens and simply write to memory ranges and have them be
transmitted when possible.

[Jon Elson]

rickman wrote:


>
> There is some interesting software they provide for working with Altera
> FPGAs called Quartus. It will let you synthesize your designs and
> measure the size. Then you can tell what size part it will fit. No
> guesswork required. :)
>

Xilinx has similar capabilities. You can desing for an arbitrary family,
then it will tell you the smalles device it will actually fit into.

I only use Xilinx, but some research SEEMS to indicate to me that
Xilinx devices may be a good deal cheaper than Altera.

All of the rest of Rick's comments are very good, and apply equally
to Xilinx.

Jon

[Theo Markettos]

rickman <gnu...@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

Theo

[glen herrmannsfeldt]

rickman <gnu...@gmail.com> wrote:
> On 12/2/2014 7:58 AM, rick.c...@gmail.com wrote:
>> Thank you for the replies and info.

(snip)

>> Would it be preferable to design and test each
>> in Quartus-II only? What about DRAM controllers?
>> And Ethernet? I plan on using Ethernet for remote
>> debugging during development and testing. And
>> do I want a dev board with VGA out to make it
>> easier? Or should I pass everything through the
>> Ethernet port?

> I'm not sure what would be easier. I've never worked with Ethernet in
> an FPGA before. I would think you could get a VGA interface working
> faster than an Ethernet interface will all the software required. Are
> you planning to run Linux on it or will you be coding to the bare metal
> without an OS? Will your Ethernet interface be a full custom or are you
> going to use an Ethernet module that provides a serial link to your CPU?

VGA is pretty easy, and there should be already done examples.
You need row and column counters, and gates to generate the hsync
and vsync. Output data from display RAM, either directly or through
a character ROM. It is FPGA outputs, through resistors, and to
the VGA pins.

For ethernet, it is usual to put a PHY chip on board, which has
the analog circuits that you can't build on an FPGA, and interface
to that.

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

-- glen

[Rick C. Hodgin]

On Tuesday, December 2, 2014 2:57:02 PM UTC-5, glen herrmannsfeldt wrote:
> VGA is pretty easy, and there should be already done examples.
> You need row and column counters, and gates to generate the hsync
> and vsync. Output data from display RAM, either directly or through
> a character ROM. It is FPGA outputs, through resistors, and to
> the VGA pins.

The ao486 project on opencores.org contains a VGA controller along with
other controllers. I figured I may look at those when the time comes.
However, from back in my OS driver development days, I remember learning
about timings for SVGA. Some of the registers driving the 3dfx voodoo3
2000 video card I was using at that time had to be programmed directly
(when no driver was available). I also remember working with the HGA
Hercules monochrome graphics adapter timings. I can see how it all fits
together now.

> For ethernet, it is usual to put a PHY chip on board, which has
> the analog circuits that you can't build on an FPGA, and interface
> to that.

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.

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.

> 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.

[rickman]

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.

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.

--

Rick

[rickman]

On 12/2/2014 3:15 PM, Rick C. Hodgin wrote:
> On Tuesday, December 2, 2014 2:57:02 PM UTC-5, glen herrmannsfeldt wrote:
>> VGA is pretty easy, and there should be already done examples.
>> You need row and column counters, and gates to generate the hsync
>> and vsync. Output data from display RAM, either directly or through
>> a character ROM. It is FPGA outputs, through resistors, and to
>> the VGA pins.
>
> The ao486 project on opencores.org contains a VGA controller along with
> other controllers. I figured I may look at those when the time comes.
> However, from back in my OS driver development days, I remember learning
> about timings for SVGA. Some of the registers driving the 3dfx voodoo3
> 2000 video card I was using at that time had to be programmed directly
> (when no driver was available). I also remember working with the HGA
> Hercules monochrome graphics adapter timings. I can see how it all fits
> together now.
>
>> For ethernet, it is usual to put a PHY chip on board, which has
>> the analog circuits that you can't build on an FPGA, and interface
>> to that.
>
> 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?

> 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?

>> 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?

--

Rick

[rickman]

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

> > 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.

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

> >> 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.

[Theo Markettos]

Pricing data is downloaded from Digikey. There were 17000 prices in all, so
to compress the dataset into something meaningful I grouped all the parts of
the same number of logical elements and the same subfamily - eg Cyclone IV
GX - and took the median of the price of each group. That gives some
measure of the middle of the range of different packages, temperatures,
speed grades etc without too many of the outliers (eg Mil Spec with crazy
prices).

Obviously in any real situation you should have coffee with the salesman and
explain how many million you're going to buy but can't afford just yet, but
there's no way to do that comparison objectively. Digikey prices aren't
ideal, but they are an example of what you would pay if you want one FPGA
tomorrow, and don't haggle with the salesman or commit to a lead time of 26
weeks.

Theo

[Theo Markettos]

rickman <gnu...@gmail.com> wrote:
> 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 Altera IP for MACs is quite nice. I used the 10G MAC recently (for the
paper I cited in my other post in fact) and it was a case of feed it a
stream of 64 bit payload words (in an Avalon stream that does the flow
control, I did this by hand in my Verilog testbench) and out pops Ethernet
frames, complete with CRC. In this case I was using an SFP+ transceiver as
my PHY, but an external PHY chip should work equally well. It gets a bit
trickier in the multi-speed MACs, when you have to talk to the PHY from
software, or when you want the MAC to also provide the
buffering/interrupts/software interface etc.

Having an external PHY/MAC usually means a bidirectional bus-style interface
(address, data, R/-W, clock, etc) which gets annoying at high speed. Or
PCIe things likewise. I don't know of any FPGAs that have integrated PHY,
though there are SFP+ Direct Attach cables which are essentially PHY-less
serial connections between MACs. Likewise SATA, USB3, etc wiring can be so
abused.

> > 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?

Sometimes it can be handy if you're doing something different to their
constraints. But at the very least keep the physical layer the same, you
can still mess with the packet structure etc. You don't want to be
debugging the PHY without a decent high speed test infrastructure. And
obviously this is only useful if you have control of both ends of the link.

Theo

[Theo Markettos]

rickman <gnu...@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

[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

[Rick C. Hodgin]

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.

> > 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.

> >>>> 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.

[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

[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.

[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

[Rick C. Hodgin]

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.

[rickman]

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

[Rick C. Hodgin]

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.
:-)

[rickman]

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]

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.

[rickman]

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

[David Brown]

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 <gnu...@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]

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

[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.

[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

[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

[David Brown]

On 03/12/14 13:05, Rick C. Hodgin wrote:
> 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!"
>

Don't be so surprised - a basic understanding of digital logic is not
actually very difficult. I was about 12 or 13 when I learned about
boolean logic, registers, ALUs and processor design. If you are
comfortable with binary, logic operations, and assembly code (on any
cpu), then digital logic design is mostly pretty simple.

There is an "ah-ha!" moment for software programmers when they first
look at Verilog, VHDL, or other HDL's, when they realise you are mostly
describing a lot of things that happen in parallel, rather than mostly
describing a lot of things that happen serially, but you seem to have
passed that.

What is not simple, of course, is actually making something useful and
working - figuring out what you need, how to make appropriate
structures, how to manage everything, how to make the design efficient
in size and space, how to avoid races, how to fit together existing
pieces, etc. And even when you know what you are doing here, there is
massive amounts of work involved.

I am not trying to discourage you here - I am just saying that you
shouldn't think you have some "natural aptitude" here (nor am I saying
that you /don't/ have a natural aptitude - but if you do, it is not yet
apparent). You are a reasonably intelligent person, with good enough
mathematical skills and plenty of experience at assembly programming,
and lots of determination and motivation - I would have been very
surprised if you had /not/ got the hang of Verilog fairly quickly.

[Rick C. Hodgin]

David,

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

[David Brown]

Does that mean you agree with what I wrote? Or that you disagree? Or
that you don't understand it? Or that you just don't want to think
about it?

[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.

[Jon Elson]

rickman 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.
>

> 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.
>

The "low end" is where I live! So, I don't know about those $18,000
FPGAs, or who the heck USES them.

I know that in very small quantities, the Xilinx XC3S50A is down to
$6.12! This is pretty amazing! The non-volatile version of the
part (XC3S50AN) is $9.91.

These prices have actually come DOWN sometime this year! I have no idea
what an equivalent Altera part would cost, due to the apples vs. oranges
of different internal architecture.

Jon

[Jon Elson]

rickman 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.
>
> 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.
>

Spartan 3 is not included in the chart. In the log-log version
(THANKS, Theo!) it is clear that the Spartan 6 does VERY well against
most other types in the price/LUT.

And, Virtex 5 is just about the WORST!

You can't compare Spartan 3 vs. Spartan 6 due to the significant changes
in the LUT capacity, unless you have some kind of correction factor
to apply. I have NO IDEA how one would establish such a factor, though!

Jon

[GaborSzakacs]

Sometime recently we went out for quotes on Spartan 6 and Artix 7 parts
looking for the best price for a part with 4 GTP transceivers. The
Artix-7 won that race, but the parts with fewer than 100K LE are
still hard to get. The smallest Artix 7 (and possibly cheapest
Xilinx FPGA) is the XC7A15T, which is only supported by the latest
Vivado release and looks to be 15-18 weeks out.

--
Gabor

[mnentwig]

Note that quite a few of the more expensive Altera eval boards ship with a
"free" design tools DVD. The problem is, to actually use those design tools
you need a license which is most definitely not free (possibly several
times more expensive than the board itself)

---------------------------------------
Posted through http://www.FPGARelated.com

[jim.bra...@ieee.org]

Ran a number of opcores.org processor designs on Spartan 3&6, Kintex-7, Cyclone 2&4 and Arria II. ("http://opencores.org/project,up_core_list,downloads" pull "family comparison; numbers below are from a more recent version)

The LUT count averages are:
S-3: 1.46 4LUTs to one ALUT
S-6 & K-7: 1.05 6LUTs to one ALUT
C-2 & C-4: 1.58 4LUTs to one ALUT
So roughly 1.5 4LUTs per 6LUT or ALUT.

Fmax generally scales with process node

(altor32, atlas_2K-base, eco32, leros, m1_core, mblite, navre, next186, pic16c5x, pdp11-34verilob, risc5, t65 & tv80; typically 1K to 4K LUT designs)

[Rick C. Hodgin]

I ended up ordering this board:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830

I was informed in email today I should receive it early next week.

I'm going to spend some time getting communication working between the
FPGA and the host computer as a debugging feature of the Oppie-1 CPU.
I will modify my Oppie-1 Debugger to receive the debug data from the
live device and display it in execution as it goes, or step-by-step,
as it does presently in the simulation.

I will also be able to send/receive updates to memory locations, change
register values, reset, restart, a true remote debugging app.

Then ... on to Oppie-2.

-----
If anyone has advice on how to get communication running most easily
on this board, I would appreciate it. Thank you in advance.

[rickman]

Doesn't look like you have a lot of options on this board. UART serial
to USB is the one comms choice. I thought you were going to use
Ethernet. That seems to be another $250, wow, more than the FPGA board.
I guess you can add one via the Arduino interface for next to nothing.

--

Rick

[Rick C. Hodgin]

On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
> > I ended up ordering this board:
> > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
> >

> > If anyone has advice on how to get communication running most easily
> > on this board, I would appreciate it. Thank you in advance.
>
> Doesn't look like you have a lot of options on this board. UART serial
> to USB is the one comms choice. I thought you were going to use
> Ethernet.

I plan to. I won't receive the PHY board I bought until the end of
December though. If there's another option I'll use that in the time
in-between, and possible after that.

I have one of the Silicon Labs chips arriving this week, but I'll need
to get a converter from its TQFP48 form factor to something usable by
human beings. I may go ahead and do that anyway. The Silicon Labs API
is very clean and straight-forward.

http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx

> That seems to be another $250, wow, more than the FPGA board.
> I guess you can add one via the Arduino interface for next to
> nothing.

[rickman]

On 12/4/2014 6:00 PM, Rick C. Hodgin wrote:
> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
>>> I ended up ordering this board:
>>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
>>>
>>> If anyone has advice on how to get communication running most easily
>>> on this board, I would appreciate it. Thank you in advance.
>>
>> Doesn't look like you have a lot of options on this board. UART serial
>> to USB is the one comms choice. I thought you were going to use
>> Ethernet.
>
> I plan to. I won't receive the PHY board I bought until the end of
> December though. If there's another option I'll use that in the time
> in-between, and possible after that.
>
> I have one of the Silicon Labs chips arriving this week, but I'll need
> to get a converter from its TQFP48 form factor to something usable by
> human beings. I may go ahead and do that anyway. The Silicon Labs API
> is very clean and straight-forward.
>
> http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx

I'm not keeping up with your choices. Why would you buy a chip that
isn't on a board? Why not use the Arduino interface? I'm sure you can
get Ethernet MAC modules for next to nothing.

--

Rick

[Rick C. Hodgin]

On Thursday, December 4, 2014 6:06:51 PM UTC-5, rickman wrote:
> > I have one of the Silicon Labs chips arriving this week, but I'll need
> > to get a converter from its TQFP48 form factor to something usable by
> > human beings. I may go ahead and do that anyway. The Silicon Labs API
> > is very clean and straight-forward.
> >
> > http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx
>
> I'm not keeping up with your choices. Why would you buy a chip that
> isn't on a board? Why not use the Arduino interface? I'm sure you can
> get Ethernet MAC modules for next to nothing.

It was free. I ordered it as a sample.

[Theo Markettos]

Rick C. Hodgin <rick.c...@gmail.com> wrote:
> I'm going to spend some time getting communication working between the
> FPGA and the host computer as a debugging feature of the Oppie-1 CPU.
> I will modify my Oppie-1 Debugger to receive the debug data from the
> live device and display it in execution as it goes, or step-by-step,
> as it does presently in the simulation.
>
> I will also be able to send/receive updates to memory locations, change
> register values, reset, restart, a true remote debugging app.
>
> Then ... on to Oppie-2.
>
> -----
> If anyone has advice on how to get communication running most easily
> on this board, I would appreciate it. Thank you in advance.

There are two Altera components that might be useful:

The JTAG UART is something that looks like a UART device, but runs via JTAG
which is connected to your PC using USB. That means it's very simple to get
a text terminal up from your FPGA. It isn't a 16550-style UART, it has a
somewhat simpler interface (and if you're using a NIOS-II processor Altera's
tools generate libraries so that printf() etc works). That means you don't
need any extra hardware to get a serial port - you just run 'nios2-terminal'
on your PC and you get a console of whatever comes out of the JTAG UART.

System Console is an Altera (Java) app that allows you to get debug access
to your FPGA, assuming your FPGA uses AXI or Altera's Avalon interconnect,
which can be built with Altera's Qsys GUI tool for building systems-on-chip.
Your components have AXI or Avalon interfaces, and you join them together in
Qsys GUI (wiring up buses, interrupts, setting addresses, etc). Qsys
synthesises a network on chip for you that implements the interconnect you
wanted (so the 'buses' are actually packet switched networks). Once you've
done that you can just drop in a debug module that allows access to those
buses from System Console via JTAG via USB. In System Console on your PC
you can write TCL scripts to access memory, change peripheral registers,
etc. Since it's plugged into your existing interconnect it can access
whatever is connected to it.

In our case we have both System Console and a CPU debug unit. The debug
unit is inside the CPU and allows insertion of instructions into the
pipeline, which means we can force it to execute code to set registers etc.
We use both that mechanism and System Console to access memory. The debug
unit is implemented using a JTAG UART, but using it as a pipe to convey
debug instructions rather than as a text terminal (we have another JTAG UART
as the console).


I'd suggest first taking the example projects supplied with the board, which
use the NIOS-II CPU, and making yourself familiar with the toolchain:
Quartus compilation
Megawizard [1]
Qsys (system-on-chip generator)
NIOS-II bare-metal software world (Eclipse editor, C compiler, Board Support
Package (BSP) of drivers for the FPGA hardware)
Programming

and only then go 'off piste'. For an example, this is the FPGA practical
course that I teach that goes through the basics (from no HDL experience to
building a heterogenous multicore system-on-chip in 24 hours of lab time):
http://www.cl.cam.ac.uk/teaching/1415/ECAD+Arch/labs/
You don't have the same board but many of the concepts should still apply.

Theo

[1] Megawizard (a tool for configuring standalone IP blocks such as PLLs) is
being phased out and rolled into Qsys, but it's still relevant at the moment

[rickman]

Why would you *order* a chip that isn't on a board? I have lots of
"sample" chips I've never used because they aren't on a board.

--

Rick

[Rick C. Hodgin]

On Thursday, December 4, 2014 7:17:19 PM UTC-5, rickman wrote:
> > It was free. I ordered it as a sample.
> Why would you *order* a chip that isn't on a board? I have lots of
> "sample" chips I've never used because they aren't on a board.

I liked the API and documentation. It's a beautiful product. If I
ever create my own mainboard, I'll probably use two or three of that
component for those reasons.

[rickman]

I can't say I follow your reasoning. You are using this chip which
requires you to find a board to mount it on... but just for a few weeks.
Then you will use the "PHY" that you have ordered. Then at a latter
time you will use this chip again? Why not just stick with this chip?
Once you figure out how to mount it where's the down side?

--

Rick

[Rick C. Hodgin]

rickman writes:
> I can't say I follow your reasoning. You are
> using this chip which requires you to find a
> board to mount it on... but just for a few
> weeks. Then you will use the "PHY" that you
> have ordered. Then at a latter time you will
> use this chip again? Why not just stick with
> this chip? Once you figure out how to mount
> it where's the down side?

You misunderstand because we're not having a
conversation, but only back-and-forth across a
written form where assumption and guesswork
enter in. And you already seem to have either a
natural bias against me, or are having difficulties
in understanding me, or both.

Don't worry about it though. It will all work out.

[rickman]

On 12/4/2014 7:59 PM, Rick C. Hodgin wrote:
> rickman writes:
>> I can't say I follow your reasoning. You are
>> using this chip which requires you to find a
>> board to mount it on... but just for a few
>> weeks. Then you will use the "PHY" that you
>> have ordered. Then at a latter time you will
>> use this chip again? Why not just stick with
>> this chip? Once you figure out how to mount
>> it where's the down side?
>
> You misunderstand because we're not having a
> conversation, but only back-and-forth across a
> written form where assumption and guesswork
> enter in. And you already seem to have either a
> natural bias against me, or are having difficulties
> in understanding me, or both.

I don't have any bias. I read what you write. If that is not clear I
ask questions. But like this time you often don't answer them. So I am
left not knowing what is in your mind. This part of the conversation
was so disjointed that I reviewed the messages you wrote, so I'm pretty
sure I am reading it correctly.

If you don't want to discuss this with me, that's fine. If you don't
respond I'll stop asking. :)

--

Rick

[Rick C. Hodgin]

Theo Markettos wrotes:

> There are two Altera components that might

> be useful...

Theo, a lot of useful information. Thank you very much.

[HT-Lab]

On 04/12/2014 23:00, Rick C. Hodgin wrote:
> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
>>> I ended up ordering this board:
>>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
>>>
>>> If anyone has advice on how to get communication running most easily
>>> on this board, I would appreciate it. Thank you in advance.
>>
>> Doesn't look like you have a lot of options on this board. UART serial
>> to USB is the one comms choice. I thought you were going to use
>> Ethernet.
>
> I plan to. I won't receive the PHY board I bought until the end of
> December though. If there's another option I'll use that in the time
> in-between, and possible after that.
>
> I have one of the Silicon Labs chips arriving this week, but I'll need
> to get a converter from its TQFP48 form factor to something usable by
> human beings. I may go ahead and do that anyway. The Silicon Labs API
> is very clean and straight-forward.
>
> http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx
>

I would look at Microchip's 28j60 controller, you only need a few wires
to talk to it (SPI) and there are lots of low cost eval boards available
on eBay and other places.

http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9

Hans
www.ht-lab.com

[Rick C. Hodgin]

On Friday, December 5, 2014 5:40:46 AM UTC-5, HT-Lab wrote:
> I would look at Microchip's 28j60 controller, you only need a few wires
> to talk to it (SPI) and there are lots of low cost eval boards available
> on eBay and other places.
>
> http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9
>
> Hans
> www.ht-lab.com

Thank you, Hans.

[vanepp]

>On 04/12/2014 23:00, Rick C. Hodgin wrote:
>> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
>>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:

<snip>

>
>I would look at Microchip's 28j60 controller, you only need a few wires
>to talk to it (SPI) and there are lots of low cost eval boards available
>on eBay and other places.
>
>http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9
>
>Hans
>www.ht-lab.com
>
>

One issue to note on the ENC28J60 is that it does not do
autonegotiation.. Thus if
you want/need full duplex you need to manually set the speed and duplex on
the
receiving port or you will get duplex mismatch and difficult to debug
problems. You
can not manually set the ports on most cheap network switches and they will
(as
the standard requires) usually default to 10 half duplex. This is pointed
out in the ENC28J60 data sheet but the implications to duplex mismatch may
not be obvious to a non network person. Using one to connect to a PC isn't
a problem as you can manually set the speed and duplex on the PC port to
match that of the ENC28J60 and run 100 full duplex (modulo spi speed of
course, I think max spi speed is 25 megabits or so on the
ENC28J60) on both ends. None the less a very cheap simple ethernet solution
if you
pay attention to its limitations.

Peter Van Epp

[Rick C. Hodgin]

The board has arrived!
The board has arrived!
Shout from the roofs, "The board has arrived!"

:-)

[sbat...@gmail.com]

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

Perhaps Terry Davis would be interested in your project.

http://www.templeos.org/Wb/Doc/Charter.html

[Rick C. Hodgin]

He's been suggested before at various times.

The Temple OS guy records responses he says
came from God when asked. His skills are most
adequate, but his general relationship with God
is keeping me at a distance.

[Rick C. Hodgin]

This is where I'm at right now.

Am I able to do everything I need from Linux? Or do I need to setup a
Windows partition?

I tried to run the Control Panel software which came with the board in
WINE. It launched, but said I needed to have Quartus installed for it
to work properly. I don't particularly want to install Quartus for
Windows in WINE as it's pretty hefty. :-)

Quartus for Linux is working just fine, as is Qsys in Linux.

The "NIOS-II bare-metal software world" you mention ... what is it?
And why Eclipse? Can I use Netbeans? :-)

And how does the C compiler enter into it? And what is the BSP for
the FPGA hardware? I was able to install my board in Quartus in Linux,
and Qsys was able to prepare for it.

I've found a few Altera videos on getting started, but the host goes
through several settings too quickly and does not go into details as
to why he's chosen what he's chosen.

Would anyone be available to get on chat with me some evening or weekend
and help get me kickstarted?

[Rick C. Hodgin]

Basically here are my goals:

(1) Altera examples (get them working correctly, learn the toolset).
(2) Create or find a simple CPU and get it working correctly.
(3) Using that simple CPU, add hardware support for my Ethernet board, and
(4) (on the host) write software to read data from the Ethernet packets.

And finally:
(5) Begin working on my LibSF 386-x40 CPU in Oppie-1 through Oppie-6 stages.

[Theo Markettos]

Rick C. Hodgin <rick.c...@gmail.com> wrote:
> This is where I'm at right now.
>
> Am I able to do everything I need from Linux? Or do I need to setup a
> Windows partition?

Linux is fine. In fact, Linux is better than Windows in some ways.

> I tried to run the Control Panel software which came with the board in
> WINE. It launched, but said I needed to have Quartus installed for it
> to work properly. I don't particularly want to install Quartus for
> Windows in WINE as it's pretty hefty. :-)

The System Builder software just generates some template Verilog files that
can go into Quartus. I usually run it in WINE when it's necessary.
Generally you just use that software to make a template once, and then
everything happens in Quartus so you can forget about the System Builder.
The Control Panel is just 'click a Windows button, and oh look the LED
lights' kind of thing - handy for checking the board you bought works, but
not that useful beyond your first 5 minutes.

> Quartus for Linux is working just fine, as is Qsys in Linux.
>
> The "NIOS-II bare-metal software world" you mention ... what is it?
> And why Eclipse? Can I use Netbeans? :-)

NIOS-II Eclispe is a (very old) version of Eclipse with some of the NIOS
tools integrated. That means there's menu options for making sample
projects, regenerating drivers, etc. It quite handy as a means of learning
what the tools do. Now I understand how it works I generally drive all of
that from Makefiles because there's less IDE magic in between me and the
build process. So I'd suggest using Eclipse just to get familiar with the
tools then you can do what you want after.

> And how does the C compiler enter into it? And what is the BSP for
> the FPGA hardware? I was able to install my board in Quartus in Linux,
> and Qsys was able to prepare for it.

A lot of the software-land tools assume you're going to put a NIOS-II
processor on your FPGA:

Qsys (the network-on-chip builder) -> BSP builder (generates a pile of C
code drivers for the Altera IP on your FPGA) -> NIOS II C compiler ->
download ELF to FPGA -> terminal to monitor your software

If you're just doing FPGA-hard-stuff you don't have any software and you can
ignore this. If you don't have a NIOS the BSP, C and ELF steps are
irrelevant, however it's worth understanding the tool flow... the best
revolutionary understands the system before they undermine it ;)

The NIOS environment is also handy as a reasonably lightweight processor to
have on hand when you want to do things that are easy in software and a pain
in hardware (like 'printf'). This comes up surprisingly often - it's just
another tool in the box.

> I've found a few Altera videos on getting started, but the host goes
> through several settings too quickly and does not go into details as
> to why he's chosen what he's chosen.

I'd start with the demos that come with your board: test them, then see if
you can rebuild them and they still work, then extend them. In the FPGA
world there are so many finicky details that, if you get them wrong, will
stop your project working - so it's worth starting with an existing working
project and building on that.

Theo

[Theo Markettos]

Rick C. Hodgin <rick.c...@gmail.com> wrote:

> And finally:
> (5) Begin working on my LibSF 386-x40 CPU in Oppie-1 through Oppie-6 stages.

On that one, I'd strongly suggest a preliminary:

Write or otherwise obtain a testsuite. This has been absolutely critical to
getting our CPU off the ground and keeping it there. When you have a
testsuite, run it against each commit of your CPU code.

Particularly when you get to more complex situations (MMU, interrupts,
exceptions, concurrency, booting a real OS), the testsuite becomes
invaluable to stamping out bugs in your design.

Theo