Which Altera to buy?

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.

Best regards,
Rick C. Hodgin

>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	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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

:-)

Best regards,
Rick C. Hodgin

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

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.

Best regards,
Rick C. Hodgin

On Thursday, December 4, 2014 6:36:37 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > 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

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?

Thank you in advance.

Best regards,
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.

Best regards,
Rick C. Hodgin

Rick C. Hodgin <rick.c.hodgin@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

Rick C. Hodgin <rick.c.hodgin@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