Beginner FPGA dev board

[obiwanjacobi]

Yes, I know, yet another thread on this topic...

I am researching the feasibility of a retro computer build project. I want to build a Z80 computer but with some modern twists.
As I was researching the video output logic options it occurred to me that an FPGA would be a sensible choice here (is it?) and I would love to have an excuse to learn something more about FPGA's and the language(s).

So that brought me to the question of what FPGA (dev board) to use.
I am looking for the following aspects:

1) cheap (below 100,= if possible)
2) small - I have no need for a couple of hundred IO pins.
3) supported by free tools
4) Easy programming (USB?)
5) No BGA - I have to be able to solder it and have no oven

Perhaps there are more criteria I have not thought of yet.

I want to program the VGA video generation in this FPGA. I might make it really fancy with sprite's hardware collision detection (C64) and what not, but I will start with dumping the video memory out the VGA port at regular intervals, which hopefully results in a coherent picture. Resolution and color depth is not decided yet and will be determined if I can interface the Z80 with large amounts of (video) memory...

PS:
I have seen the #636 video Dave made but I am wondering if there are any recent developments that may be options for me.

[PA0PBZ]

Or http://www.micro-nova.com/mercury/

Smaller & cheaper.

[Lunasix]

Digilent Cmod S6 ? After, Spartan 6 is available in tqfp for smaller parts.
Microsemi A3Pxxx is also at a low price and with usable footprints, but Xilinx gives you more (dsp blocks).

[tggzzz]

Or http://www.micro-nova.com/mercury/

Smaller & cheaper.

And only one ground pin on a 64-way IO connector Good luck getting signal integrity with that!

[daybyter]

There is a zx81 Version for those cyclone 2 min dev boards. About 16,- at ebay.com.

[tggzzz]

And only one ground pin on a 64-way IO connector Good luck getting signal integrity with that!

Horribly design failure.

But this can be solved by using driven low IO pins to emulate GND, and it is actually a technique usually used to solve SSO problem.

Of course, a wrong register writing (say, driving a grounded IO low) can dry the chip.

Anyway, fail.

That fail is all too common on "amateur" boards, typically made by people with little practical experience of high speed analogue electronics. And all electronic signals are analogue[1] even if they are interpreted in a non-linear fashion.

[1] except for photon counting applications and very small geometry devices

[obiwanjacobi]

The DE0 Nano looks a little heavy. I don't think I have any need for a hard processor.

The mercury's form factor looks very appealing - not sure about having one gnd pin. I have no experience with this so I go with what is said here. The highest frequency will be the clock that drives the FPGA (logic) which drives the transfer mechanism to output the video.

The board would need at least 16+8+4 IO lines for accessing the external video ram (forgot to mention this earlier). The rest of the remaining IO I will probably use for address decoding etc. (although I wanted to make the design modular...)

I would not mind buying a dev board with a larger/heavier FPGA than I need right now, IF I can down-scale the design to something smaller and compatible (and what will be compatible?).

Looking at the Altera site the MAX10 looks pretty good - haven't studied it yet in detail. Not sure about the packages it comes in though.
Would that be something that is suitable to start with as a beginner?

Another thing occurred to me: Because the exact FPGA is not too critical, would it stand to reason to let the quality of the tools dictate what brand I choose? In that case which brands have the best tools? 

@daybyter: sorry I couldn't decipher your hint on the zx81 version of the Cyclone II on ebay? Could you be more specific. Is it ZX81 programmed into a Cyclone? - that is not what I need.

Thanx for the suggestions.

[PA0PBZ]

But this can be solved by using driven low IO pins to emulate GND, and it is actually a technique usually used to solve SSO problem.
Of course, a wrong register writing (say, driving a grounded IO low) can dry the chip.

That's what I was thinking, and luckily most IO is buffered so you can afford to make that mistake.
 

[tggzzz]

The highest frequency will be the clock that drives the FPGA (logic) which drives the transfer mechanism to output the video.

No.  The highest frequency is determined solely by the signal rise time; the period is irrelevant. You almost certainly need to use transmission lines for signals to/from FPGAs.

If you have many signals changing on the same clock, you have to consider ground bounce.

Both those serious problems are ameliorated by more ground pins.

[miguelvp]

Regarding the BeMicro Max10

There is a wiki for it:
http://www.alterawiki.com/wiki/BeMicro_Max_10

And they have over 300 on stock at $30, there is a listing for cheaper but shows no stock
http://components.arrow.com/part/search/bemicro

If you need more I/O pins there is an 80 pin edge connector on the side, I did link the source to the connector in other threads that you probably can find by doing a search in the forum for MAX10

It is an expensive connector as I recall, but there is plenty of I/O to be had without using that, unless you have some requirement that needs to use one of those pins for some specialized functionality that's only present there, but I didn't look in detail if that's the case.

Edit: I just recalled there was some errata regarding some of the pins, but that could be for the BemicroCV (cyclone V) If I find the link in this forum I'll post it in here.

Edit2: The wrong pin assignments in the datasheet was for the BeMicroCV that affected the on board LED assignments:

http://longchute.herokuapp.com/2014/09/23/arrow-bemicro-cv-notes/

[daybyter]

@daybyter: sorry I couldn't decipher your hint on the zx81 version of the Cyclone II on ebay? Could you be more specific. Is it ZX81 programmed into a Cyclone? - that is not what I need.

http://www.ebay.com/itm/1PCS-ALTERA-FPGA-Cyslonell-EP2C5T144-Minimum-System-Learning-Development-Board-/311369884158?hash=item487f1761fe:g:mTMAAOSwpdpVZxKv

I think it has 89 I/O lines IIRC.

You'll need a USB blaster to program it:

http://www.ebay.com/itm/altera-Mini-Usb-Blaster-Cable-For-CPLD-FPGA-NIOS-JTAG-Altera-Programmer-new-/161597061343?hash=item259fef78df:g:hTIAAOSwPYZU2wSX

There's a project, in which they implemented a zx81 computer on this board.

[Rasz]

http://www.ebay.com/itm/1PCS-ALTERA-FPGA-Cyslonell-EP2C5T144-Minimum-System-Learning-Development-Board-/311369884158?hash=item487f1761fe:g:mTMAAOSwpdpVZxKv

I think it has 89 I/O lines IIRC.

You'll need a USB blaster to program it:

http://www.ebay.com/itm/altera-Mini-Usb-Blaster-Cable-For-CPLD-FPGA-NIOS-JTAG-Altera-Programmer-new-/161597061343?hash=item259fef78df:g:hTIAAOSwPYZU2wSX

very much this
its cheap and unbelievably powerful compared to ordinary microcontrollers, great for a first fpga project

[obiwanjacobi]

Ok I've looked at several others, mainly Latice and Xilinx and they all claim to be the latest greatest so no info there.

In the spirit of "you have to start somewhere" I bought the ebay Cyclone II board and also came across this board which I also bought (I'm on a roll here) - an Altera Max II. From what I understand not strictly an FPGA but should be fun anyway.

All I need now is a whole lot of (bi-derectional) 5<>3.3 volt level shifters (any affordable ICs out there?) and a whole lot of SRAM and I am good to go.

Thanx everyone - onto the next adventure.

[daybyter]

Congrats! Download Altera Quartus2 13.0sp1. It's the latest version, that works with Cyclone2. You don't need an actual device to write the code and simulate it. If you use linux, you might want to use it in an virtual machine. I use a virtualbox 32 debian image, because Quartus seems to use a mixture of 64 bit and 32 bit code.

[Rasz]

dont forget the jtag, you can make byteblaster clone if you have old computer with lpt, or ebay again

[obiwanjacobi]

Yeah I found the software... holy f*$%!   
That will take some YouTube-watching to get my head around that! 

BTW: if you download the cyclone_web-13.0.1.232.qdz file, the device installer does not see it. Remove the '_web' and it works.

EDIT: No worries have the blaster too 

[Macbeth]

You should have some fun! I recently got one of those cheap MAX II EPM240 CPLD boards just to dip my toe in the water. Absolutely no documentation of course!  But that was kind of expected.

I already had a cheap clone USB Blaster anyway but you will need one. One thing my current one crashes Windows 10 but works great in Linux (as does Quartus II).

Anyway, I didn't want to start with VHDL/Verilog, but the old fashioned schematic routing of logic chips like 74 series. Just like I would a board back in the early 90's. Quartus II has all that stuff built in 

I am used to microcontrollers and I was bashing my head trying to figure out where to get a clock from? I mean a clock is fundamental and this CPLD has a 50MHz clock. I want to drive my shift registers and flip-flops... but with what?  I wasted a lot of time looking up PLL's and other stuff available on higher FPGAs but I just wanted a simple clock! Where is the clock register? 

It's one of those things that are more electronics engineer than programmer brain when you suddenly realise that you have all the pins you want available and one of those is the actual pin the crystal is connected to. I buzzed it out with my multimeter, found the pin, then used that as the input to my divider chain... Revelation! It's so bleeding obvious in hindsight! 

I've also ordered what seems a very cheap Cyclone IV dev kit on aliexpress http://www.aliexpress.com/snapshot/7097721248.html this one has some documentation and source code which I am reading while I wait for delivery!

[bingo600]

@Macbeth

Here you go

/Bingo

[obiwanjacobi]

I delved into VHDL first because I realized that all tutorials were meaningless with knowledge of the concepts. First watched Altera's VHDL Basics via https://www.youtube.com/user/deepaksh0607 and now I am wrestling through https://www.youtube.com/channel/UCbUe5SLMSZlSzCuJP81lU0A. I think I'm getting my head around this (very verbose) language.

[Macbeth]

@Bingo - Thanks! For some reason google chrome chokes at the source code zip! I downloaded it with IE/Edge ok though

@obiwan - I have put off the VHDL stuff for now as was only trying to implement e.g. Daves old 7 seg + logic IC clock using something as simple as a CPLD rather than all those IC's. However, back in the 80's we never really had 50MHz clocks to divide and the amount of shift registers to divide down to 1 or 2 Hz is silly on a schematic and perhaps a good excuse to implement in VHDL instead.

[obiwanjacobi]

Yeah, I've seen the clock video, loved it!

For simple stuff you can fallback on the ICs you know and replicate them in VHDL, but when it gets more complicated you can describe the behavior you're after and the compiler will add the registers, counters and adders etc.
I have little experience in working with bare 74 logic (not a complete noob - but no expert for sure) so I really dig that VHDL supports a higher level abstraction.

First I have to fix the QuartusII software - I don't see my installed devices 

[marcopolo]

I think I'm getting my head around this (very verbose) language.

Try Verilog 

[obiwanjacobi]

Well - I have looked into the options of all the different languages (including drawing gates) and it seemed to me that VHDL is a 'standard' in Europe and 'verilog' in the US. I disregarded the C/C++ language because I could not see that it would be a good match (using a software language to fix a hardware problem). I also disgarded AVDL (Altera proprietary language) because I wanted to learn something that would also be useful elsewhere.

So indeed the choice was basically between Verilog and VHDL. At a first glance of the syntax I chose VHDL (arbitrarily). To my critical mind all these languages seem archaic and so last century -- and I love the 90's look of the software too! (NOT!).

But for now I am stuck because there is a problem with the Quartus web license and it does not show any devices and does not compile...

Which gives me some time to think about the design of what I am trying to build and how to implement it. I was wondering if there were any 'Design Patterns' and 'Best Practices' (as you have for software development)? I am sure I will make plenty of rookie mistakes but reading some simple tips and tricks could weed out e few before I even begin.

I have been watching (VHDL) YT video's all weekend just to get immersed in the material.

[tggzzz]

Which gives me some time to think about the design of what I am trying to build and how to implement it. I was wondering if there were any 'Design Patterns' and 'Best Practices' (as you have for software development)? I am sure I will make plenty of rookie mistakes but reading some simple tips and tricks could weed out e few before I even begin.

Yes, good questions. There are many books and articles about VHDL around, including syntax and structure and style guidelines - but few at the design pattern level.

In its place, I like the "two process" pattern described in http://www.gaisler.com/doc/vhdl2proc.pdf

I would like to see design patterns for directory structure, and for timing constraints in systems with multiple clock domains. Please let me (us!) know of suitable examples.

[obiwanjacobi]

Looks like Quartus 13.0SP1 does not work correctly on Windows 8.1 ...   
So that CycloneII board is not for you if you have Windows 8.1 or up (?).
I will probably abandon it (before I even have it  ) and see if the newest Quertus version will run and what devices are supported and pick one of those...

Looking at the two processes pattern now. Looks interesting but also raises some questions - like: this only works if you also manage a suitable hierarchy..?

Anyway before I put my thoughts to paper (or forum) I'd better get some hands-on experience first 

[hamster_nz]

Which gives me some time to think about the design of what I am trying to build and how to implement it. I was wondering if there were any 'Design Patterns' and 'Best Practices' (as you have for software development)? I am sure I will make plenty of rookie mistakes but reading some simple tips and tricks could weed out e few before I even begin.

Compared with software, the "maps to static 2D hardware" nature of FPGAs doesn't allow as much freedom as software development to stuff things up, and alternative approaches often end up as being different ways to express the same finished product.

Here's a few recurring things:

• Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines
• A shift register based sequencer - a single bit moving through a shift register sequences events (essentially a one-hot FSM)
• Processing pipelines - a module that performs it work over a number of cycles, with each cycle using the output of the last
• Decoupling the data flows between modules - usually achieved using FIFOs
• Stream processing - detecting and acting on sequences in a stream (eg. processing date packets, adding/checking CRCs, PCM audio, digital video...)
• LFSRs - and how they are used for CRCs, ECC, BCH, random number generators, scramblers. Very common in interfaces
• DSP optimization methods - eg cascading vs adder trees. Very architecture dependent
• time-slicing resource usage - for example multi-pumping logic
• High speed serial interfaces (SERDES)
• DDR i/o
• Forwarding clocks to the outside world
• Coding schemes - TMDS, NRZ, Manchester, 8b/10b
• Debugging infrastructure - designing for debugging, how to capture signals and bring them to the outside world
• Synchronising async signals - two or three stage synchronisers
• Handshaking between clock domains
• PWM - being able to control frequency, duty and phase of signals
• Clocking structures - PLLs, clock buffers, clock routing networks, clock switches
• Timing optimizations - a tool-bag of tricks to make things run fast
• The whole world of test bench coding
• Input Filtering - deglitching/debouncing

[1uk3]

Did you try this fix http://help.ece.ubc.ca/Altera? (scroll down)
I think i used 13.0 on a Win8.1 machine.

[obiwanjacobi]

Did you try this fix http://help.ece.ubc.ca/Altera? (scroll down)
I think i used 13.0 on a Win8.1 machine.

No I didn't, thanx!

@hamster_nz: excellent list. I do not understand all of the acronyms but it's a nice place to start research.

As with any programming there is the magic of translating a problem to the correct (most optimum) constructs in the language...
That needs practice 

[tggzzz]

Looking at the two processes pattern now. Looks interesting but also raises some questions

All design patterns should do that - they aren't answers but hints as to answers that have frequently been useful.

- like: this only works if you also manage a suitable hierarchy..?

There is no extra difficulty. If anything, thinking in terms of FSMs beneficially shapes the hierarchy, design and implementation.

Managing the hierarchy is vital for absolutely everything w.r.t. hardware design, from FPGA internal design, through PCBs, through cabinets, through software, to complete systems.

[nowlan]

Was that list from hamster what C could manage? or just syllabus from a Uni fpga course?

[Moondeck]

Yes, I know, yet another thread on this topic...

I am researching the feasibility of a retro computer build project. I want to build a Z80 computer but with some modern twists.
As I was researching the video output logic options it occurred to me that an FPGA would be a sensible choice here (is it?) and I would love to have an excuse to learn something more about FPGA's and the language(s).

So that brought me to the question of what FPGA (dev board) to use.
I am looking for the following aspects:

1) cheap (below 100,= if possible)
2) small - I have no need for a couple of hundred IO pins.
3) supported by free tools
4) Easy programming (USB?)
5) No BGA - I have to be able to solder it and have no oven

Perhaps there are more criteria I have not thought of yet.

I want to program the VGA video generation in this FPGA. I might make it really fancy with sprite's hardware collision detection (C64) and what not, but I will start with dumping the video memory out the VGA port at regular intervals, which hopefully results in a coherent picture. Resolution and color depth is not decided yet and will be determined if I can interface the Z80 with large amounts of (video) memory...

PS:
I have seen the #636 video Dave made but I am wondering if there are any recent developments that may be options for me.

Get a Numato board. Waaay under 100 bucks, and non-bga. Free tools and programing by USB

[obiwanjacobi]

In the logs I saw:

Script stderr: Qt: Untested Windows version 6.2 detected!

I followed this patch (bottom of the page)
http://help.ece.ubc.ca/Altera#Microsoft_Windows_8.2F8.1_Warning

and had a problem with a file 'current' that was in the patch and a folder 'current' in the target (the original install). I skipped it.

but it didn't work...
I still have the same error.

So uninstall it is.
I found a page  (can't remember where) for the compatibility for Quartus v15 which still didn't support the simulator on Windows 8.1.
But I guess that is better than nothing.

Looks like I need a separate laptop with all old software for doing EE stuff ...   

[Bassman59]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

[tggzzz]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

That's unnecessarily dogmatic and unbalanced to the point of being wrong. Such a statement would benefit from indicating either the "Real Good Reasons" or when and why a different particular pattern is (in the author's opinion) preferable.

Personally for all but the most trivial FSMs, I find the two process pattern matches my thinking patterns during design, and is easy to debug and modify during continued development.

[hamster_nz]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

For those playing at home, the two-process paradigm is as follows...

1. Declare a record to hold all your state information
2. You have two instances of that record - one which is the current_state, and one which is the next_state.
3. One process takes the current_state, and all of the module's inputs, and populates the "next_state" record. It usually starts with "next_state <= current_state;" to default all values, and then overwrites members in next_state that needs to change
4. The second small-but-important process is clocked, and just assigns the current_state from next_state
5. I would also add that you should only use signals not variables.

In the process that does all the work, for all assignments the left hand side should be next_state.something, and everything else should be "current_state.something"

Advantages.
1. Your design structure matches the actual hardware implementation (combinatorial logic & flipflops to hold state)
2. Delayed assignment becomes a non-issue, as you never assign into "current_state"
3. It is a strong enough framework to force you into thinking differently about your design,

In some ways it is like training wheels for VHDL. I used it for a few months until I fully groked it, then went back to single process design with a much-improved mental model of what I was doing from then on. I sometimes haul it out of the bag when designing pipelines, as when you use appropriately named members in the state record you can see if you have buggered up the pipeline (e.g. stage 2 state should only be populated using the values derived from stage 1's state)

If bassman59 finds it error prone, easy to screw up and difficult to maintain then he is doing it wrong.

[1uk3]

with a much-improved mental model of what I was doing from then on

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

[tggzzz]

with a much-improved mental model of what I was doing from then on

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

I've seen some truly dreadful implementations of FSMs in my time which had such deeply nested case and if statements that, when they had to be slightly modified, people couldn't be sure that their change didn't affect more than they expected. Bad design and implementation, sure - but it instills a strong desire to write code that is readable and easily mutatable.

The two and three process patterns are an excellent way of encouraging and aiding that objective.

[obiwanjacobi]

Looks very good to me, but I am not at that point yet. Still learning the basic syntax and structure of a VHDL program. Took me like 20 compile-passes to get a simple counter to compile (from scratch - no copying).

I couldn't find any decent language/syntax reference or IEEE library documentation which made it harder than it had to be. I also found that not all IEEE libraries are the same!? I got an error that no '+' operator was on a std_logic type (Altera), while I saw examples for Xilinx (or other) do just that... (count = count + 1)

I am also amazed at how bad the intellisense is - being used to Visual Studio...

Lots to learn...

[Someone]

I couldn't find any decent language/syntax reference or IEEE library documentation which made it harder than it had to be. I also found that not all IEEE libraries are the same!? I got an error that no '+' operator was on a std_logic type (Altera), while I saw examples for Xilinx (or other) do just that... (count = count + 1)

You can always switch to Verilog and enjoy a complete lack of typing

with a much-improved mental model of what I was doing from then on

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

I've seen some truly dreadful implementations of FSMs in my time which had such deeply nested case and if statements that, when they had to be slightly modified, people couldn't be sure that their change didn't affect more than they expected. Bad design and implementation, sure - but it instills a strong desire to write code that is readable and easily mutatable.

The two and three process patterns are an excellent way of encouraging and aiding that objective.

As with most coding its best to be pragmatic and write code that works and is understandable rather than have rules. I've not seen many straight multiprocess designs in the wild and its often much clearer to mix styles within a single FSM. The tools have advanced enough that they can extract the state map from just about anything and I'm not having to try and coerce the synthesis to infer what I want anymore.

[tggzzz]

with a much-improved mental model of what I was doing from then on

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

I've seen some truly dreadful implementations of FSMs in my time which had such deeply nested case and if statements that, when they had to be slightly modified, people couldn't be sure that their change didn't affect more than they expected. Bad design and implementation, sure - but it instills a strong desire to write code that is readable and easily mutatable.

The two and three process patterns are an excellent way of encouraging and aiding that objective.

As with most coding its best to be pragmatic and write code that works and is understandable rather than have rules. I've not seen many straight multiprocess designs in the wild and its often much clearer to mix styles within a single FSM. The tools have advanced enough that they can extract the state map from just about anything and I'm not having to try and coerce the synthesis to infer what I want anymore.

That's reasonable and justifiable.

It becomes less clear-cut when, over the lifetime of a product, there are many small mods and tweaks. Each mod/tweak can be individually pragmatic (especially from a business perspective), but the cumulative effect can be terrible. In the worst case I've seen the product became a millstone for the company and its clients!

Fortunately that is rare, while the lessons should be advertised and understood, it is unwise to base policy on lunatic extremes.

[ale500]

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

f*ck everything I want the 5-process FSM and and I want it now ! 

[obiwanjacobi]

"There's nothing you cannot fix with another level of indirection" 

[tggzzz]

"There's nothing you cannot fix with another level of indirection" 

The signal processing equivalent is "all problems can be solved by integrating for longer"

[Bassman59]

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

f*ck everything I want the 5-process FSM and and I want it now ! 

[urlhttp://www.theonion.com/blogpost/fuck-everything-were-doing-five-blades-11056]FIVE FUCKING BLADES.[/url]

[hamster_nz]

I also found that not all IEEE libraries are the same!? I got an error that no '+' operator was on a std_logic type (Altera), while I saw examples for Xilinx (or other) do just that... (count = count + 1)

About to start a flame war I guess...

The only one you want is

 use IEEE.NUMERIC_STD.ALL;

Everything that really is a number, need to be declared as either 'signed' or 'unsigned' - e.g.

   constant hVisible   : unsigned(11 downto 0) := to_unsigned(1920,12);

(Note the conversion function "to_unsigned(value, length)" used to initialize it)

You then use the type conversion functions if you decide to convert to/from the STD_LOGIC_VECTOR type:

- "unsigned()" to convert a STD_LOGIC_VECTOR to an unsigned binary number with the same length
- "signed()" to convert a STD_LOGIC_VECTOR to an signed binary number with the same length
- "std_logic_vector()" to convert a binary number to a STD_LOGIC_VECTOR
- "std_logic()" to convert a binary digit to a STD_LOGIC bit

VHDL Array lookups (e.g. inferred RAMs and ROMs) are a bit clunky, but workable using the "to_integer()" function. E.g:

Code: [Select]

    colour <= palette(to_integer(unsigned(iterations_in)));

And always keep your module's external interfaces as STD_LOGIC or STD_LOGIC_VECTOR. This keeps the higher level structural modules clean of random data types. It is OK for a module's generics to be integers or naturals.

Follow these guidelines and pretty much all your data type problems will go away.

[tggzzz]

About to start a flame war I guess...
The only one you want is
 use IEEE.NUMERIC_STD.ALL;
......
And always keep your module's external interfaces as STD_LOGIC or STD_LOGIC_VECTOR. This keeps the higher level structural modules clean of random data types. It is OK for a module's generics to be integers or naturals.

Follow these guidelines and pretty much all your data type problems will go away.

...but you might lose other benefits.

VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!

[hamster_nz]

VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!

I think it is more like telling a 'C' newbie not to use malloc() and free() until they have a firm understanding of the basic language.

The difference is that unlike 'C' without malloc() and free(), following the above rules you can still write anything that can be synthesized in an FPGA, and still keeping within VHDL's strong typing paradigm.

Every time I see VHDL code with an integer port definition on a module a little part of me cries...

I guess your clause of "...and should, where beneficial" is the key.... I can't think of many cases where doing anything else is beneficial!

[tggzzz]

VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!

I think it is more like telling a 'C' newbie not to use malloc() and free() until they have a firm understanding of the basic language.

The difference is that unlike 'C' without malloc() and free(), following the above rules you can still write anything that can be synthesized in an FPGA, and still keeping within VHDL's strong typing paradigm.

Not really. If you want to continue the analogy without looking at the larger picture, then realise that malloc/free are part of a library not the C language. So not using malloc/free is(if anything) equivalent to not using a PLL/clock multiplier or FIFO.

Every time I see VHDL code with an integer port definition on a module a little part of me cries...

I guess your clause of "...and should, where beneficial" is the key.... I can't think of many cases where doing anything else is beneficial!

Reread the first part of the sentence to get an inkling of the "many" cases where it is useful.

I would guess that you have only been involved in implementing devices, never designing them - especially in a system context. Consider especially the design validation phase, which as I presume you know, occurs well in advance of the implementation and verification phases. Using the same tool for validation and verification has significant advantages, which is one reason why VHDL's "architecture X of entity Y" concept exists.

If you want a trivial pedagogical DSP example from my dim and distant past when DSP blocks didn't exist, consider having to implement a module that computes "x - 4*y + 640" in a single clock cycle. Integers are the natural representation of what is intended and meant, so use them! And always use them in the test bench, of course.

You should also consider that simulations of integers (for example) can run faster than simulations of gates, since they map directly onto the CPUs instructions. That can be very significant in large designs. Later on the "integer processing" is incrementally replaced by its gate-level equivalent, via adding other architectures to individual models.

[obiwanjacobi]

As with every new language, I first need to get past the point where I need to lookup every other word 

Then I will start to think about structure and patterns & practices. I'm still in the "hello world" stage.
The VGA- and glue-logic I am wanting to make should not be to create for I have already found several examples - on the other hand I will want to really understand why it works. But I will probably lean toward the more high-level take on the language - simply to offload some of the details to the compiler/synthesizer.

For now I am content when what I type compiles 

[tggzzz]

As with every new language, I first need to get past the point where I need to lookup every other word 

Then I will start to think about structure and patterns & practices. I'm still in the "hello world" stage.
The VGA- and glue-logic I am wanting to make should not be to create for I have already found several examples - on the other hand I will want to really understand why it works. But I will probably lean toward the more high-level take on the language - simply to offload some of the details to the compiler/synthesizer.

For now I am content when what I type compiles 

Sounds familiar!

As I'm sure you will discover, one HDL is much like another HDL in the same way one procedural HLL is much like another procedural HLL. But of course there are very significant differences between HLLs and HDLs. However, arguably some enterprise-level and cloud-level environments are becoming more like HDLs in that they emphasise structural composition of pre-existing building blocks; about time too

As you note, the trick is to understand what they are and aren't doing for you.

[KE5FX]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair.   Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.

[Scrts]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed. FPGA design is difficult for beginner and takes years of time to learn. I remember spending days and weeks solving some issues, especially when getting IP from somewhere else and finishing up rewriting everything from scratch.
It takes lots of theory, lots of practice, failures and successes to reach a level where you feel confident. And after 3 years of HDL design I felt that I don't know so many things... On the other hand, that's why it's so awesome and interesting!

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair.   Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.

[tggzzz]

Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair.   Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.

This advice and is timeless, and applies to hardware, software and I'm sure many other endeavours:

• make it so that the implementation transparently and directly corresponds to the high-level design
• when, not if, the high-level design mutates in the light of experience or new requirements, ensure that the implementation technique allows easy and simple modifications in which the desired changes and only the desired changes, occur
• such changes should include the addition of new states, adding/subtracting events to a state, changing the processing when an event occurs
• ensure the implementation technique allows easy debugging, which must include seeing which events occurred in which state and in which order. That has the bonus that it can make it easy to prove that another module is misbehaving, which is especially valuable if the other module is from another company!
• use common well-supported tools for defining the FSM; don't invent yet another FSM description language - unless you are prepared to provide tool support and train new people in its use

You may take a hit in the short term, but in the long term those techniques have been very valuable to me personally and to other people in several companies.

For VHDL FSMs, the two process techique is one suitable design pattern. There are valid other design patterns, but they should also be measured against the above criteria.

[Bassman59]

About to start a flame war I guess...
The only one you want is
 use IEEE.NUMERIC_STD.ALL;
......
And always keep your module's external interfaces as STD_LOGIC or STD_LOGIC_VECTOR. This keeps the higher level structural modules clean of random data types. It is OK for a module's generics to be integers or naturals.

Follow these guidelines and pretty much all your data type problems will go away.

...but you might lose other benefits.

VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!

Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.

[Bassman59]

I couldn't find any decent language/syntax reference or IEEE library documentation which made it harder than it had to be. I also found that not all IEEE libraries are the same!? I got an error that no '+' operator was on a std_logic type (Altera), while I saw examples for Xilinx (or other) do just that... (count = count + 1)

You can always switch to Verilog and enjoy a complete lack of typing

with a much-improved mental model of what I was doing from then on

I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

I've seen some truly dreadful implementations of FSMs in my time which had such deeply nested case and if statements that, when they had to be slightly modified, people couldn't be sure that their change didn't affect more than they expected. Bad design and implementation, sure - but it instills a strong desire to write code that is readable and easily mutatable.

The two and three process patterns are an excellent way of encouraging and aiding that objective.

As with most coding its best to be pragmatic and write code that works and is understandable rather than have rules. I've not seen many straight multiprocess designs in the wild and its often much clearer to mix styles within a single FSM. The tools have advanced enough that they can extract the state map from just about anything and I'm not having to try and coerce the synthesis to infer what I want anymore.

Exactly.

The original reason for the two- (and three-) process state machine was that Synopsys didn't support it back in the early 90s. Once better synthesis tools became available, that arbitrary limit went away.

[hamster_nz]

Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.

I must be missing something. Can you point me at a sizable project that uses the techniques you are suggesting, so I can look through the code?

But for now, here is my experiment I performed tonight. For a project I am working on. I get a 12-bit value from an ADC, and I need to scale an ADC reading by 503.75/4096 (or 2015/16348). So I coded it both ways, and implemented it in hardware.

So if I understand your suggested style, using integers or naturals on the interface makes sense, doubly so to a HDL newbie. It also makes sense to use '*' and '/' operators too.

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity using_ints is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in integer;
           temp        : out integer);
end using_ints;

architecture Behavioral of using_ints is
begin

process(clk)
    begin
        if rising_edge(clk) then
            temp <= adc_reading * 2015 / 16384;
        end if;
    end process;

end Behavioral;
Perfectly reasonable code, and implements and tests correctly. With the inputs and output registered outside of the his module, the usage within the module is 60 LUTs, 9 Flipflops, 1 DSP block, Fmax 117 MHz. I also tried it with 'naturals' rather than integers, with the same results.

Now using STD_LOGIC_VECTOR as the interface, and hinting at what is really efficient to do.

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity using_slv is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in STD_LOGIC_VECTOR (11 downto 0);
           tempx        : out STD_LOGIC_VECTOR (8 downto 0));
end using_slv;

architecture Behavioral of using_slv is

    signal adc_reading_x2048 : unsigned (22 downto 0);
    signal adc_reading_x32   : unsigned (16 downto 0);
    signal adc_reading_x1    : unsigned (11 downto 0);
    signal result            : unsigned (22 downto 0);
begin
    adc_reading_x2048 <= unsigned(adc_reading) & to_unsigned(0,11); 
    adc_reading_x32   <= unsigned(adc_reading) & to_unsigned(0,5); 
    adc_reading_x1    <= unsigned(adc_reading); 
    temp              <= std_logic_vector(result(result'high downto 14));   -- Divide by 2^14 = 16k

process(clk)
    begin
       if rising_edge(clk) then
         result <= adc_reading_x2048 - adc_reading_x32 - adc_reading_x1;
       end if;
    end process;   
end Behavioral;

Module usage 23 LUTs, 8 Flipflops, Fmax 384 MHz - less than half the LUTs, no DSP blocks, and three times faster.

To me, the results speak for themselves...

[tggzzz]

The original reason for the two- (and three-) process state machine was that Synopsys didn't support it back in the early 90s. Once better synthesis tools became available, that arbitrary limit went away.

While one particular tool may not have supported a particular design pattern at some time in the past, that is neither a reason to use nor to avoid the design pattern.

Ob joke: "Mummy, why do you cut the end off the leg of lamb before roasting it?". "Because that the way granny always did it; why don't you ask her?". Granny looks puzzled, then remembers "Because I had to do that to fit it in the small oven".

The key points about a design pattern is that it is easily recognisable, understandable, supports good design/implementation/modification practices. Two process FSM are one such design pattern, and it is perfectly reasonable to continue to use it.

[tggzzz]

Bassman59: you might like to reflect that you seem to be getting a reputation, viz https://www.eevblog.com/forum/open-source-kicad-geda/the-new-version-of-kicad-is-a-fact/msg814376/#msg814376

[Bassman59]

Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.

I must be missing something. Can you point me at a sizable project that uses the techniques you are suggesting, so I can look through the code?

But for now, here is my experiment I performed tonight. For a project I am working on. I get a 12-bit value from an ADC, and I need to scale an ADC reading by 503.75/4096 (or 2015/16348). So I coded it both ways, and implemented it in hardware.

So if I understand your suggested style, using integers or naturals on the interface makes sense, doubly so to a HDL newbie. It also makes sense to use '*' and '/' operators too.

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity using_ints is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in integer;
           temp        : out integer);
end using_ints;

architecture Behavioral of using_ints is
begin

process(clk)
    begin
        if rising_edge(clk) then
            temp <= adc_reading * 2015 / 16384;
        end if;
    end process;

end Behavioral;
Perfectly reasonable code, and implements and tests correctly. With the inputs and output registered outside of the his module, the usage within the module is 60 LUTs, 9 Flipflops, 1 DSP block, Fmax 117 MHz. I also tried it with 'naturals' rather than integers, with the same results.

Rookie mistake: You used integer for the ports. Without a range, an integer is 32 bits wide. In your std_logic_vector example, the vector sizes are 12 bits for the input and 9 bits for the output. Since the integer operations are all 32 bits wide, of course you will have a lot of extra logic and as such lower performance.

Using a ranged integer (or natural) on a port can be cumbersome, as you need to declare a subtype with the range and for that subtype to be visible in the top-level entity as well as the lower-level, you need to put it in a package.

A better solution would be to not use an integer type, but instead use the unsigned type from numeric_std. You can declare the ports as an unsigned(11 downto 0) and unsigned(9 downto 0) instead of std_logic_vector, saving yourself the type conversion. numeric_std overloads the usual math operators for unsigned, and you can also manipulate the vectors like you did in your second example.

[Bassman59]

Bassman59: you might like to reflect that you seem to be getting a reputation, viz https://www.eevblog.com/forum/open-source-kicad-geda/the-new-version-of-kicad-is-a-fact/msg814376/#msg814376

I know; I read the thread. Apparently, the snake person thinks I am some sort of God. That's his delusion, and he is projecting. Basically, he assigns to me the same stringent adherence to dogma that he holds himself. My argument is not that "My Way Is The Only Way," but he seems to think it so. Whatever. He is welcome to re-invent the wheel with every design.

As for the two-process state machine, that is a design idiom up with which I will not put! The record idea is clever, but I don't see how it offers an advantage over the single synchronous process. After all, you're going to register your machine outputs and the state variable, anyway.

[alan.green@gmail.com]

Does anyone have thoughts on the FleaFPGA Uno?

http://www.fleasystems.com/fleaFPGA_Uno.html

On the plus side, it is programmable via USB, has HDMI and USB connectors on-board, and does ADC. On the negative side, with the Arduino form factor, there aren't a lot of spare GPIO pins.

[alexanderbrevig]

Also, this seems to be a good alternative for beginners: https://www.eevblog.com/forum/microcontrollers/the-nandland-go-board-the-first-fpga-board-you-should-buy/

[nowlan]

Was expecting to hear something about the ARTY that was in recent mailbag vlog.

[nixfu]

Just purchased this dev board from china.

$37 for a fully stocked dev board with an Altera Cyclone IV seemed like a decent price. It has onboard LED's, LCD, 7segs, buttons, switches, speaker, VGA out, and more..it even includes a USB blaster.

http://www.aliexpress.com/item/USB-BLASTER-LCD1602-ALTERA-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/793643076.html

[Macbeth]

My $37 Cyclone IV board and accessories arrived from China this morning! 

One thing I am really happy with is the included clone Altera USB blaster actually works perfectly in Windows 10. I initially thought this part was redundant, as I had one already, but for the bargain price of the whole kit, what the hell? Same goes for the TTL UART. I've got a couple already.

My old USB Blaster worked in Win 7 and Linux but would hang in Win 10 and/or blue screen. This new one works perfectly. So glad because it has been such a pain rebooting to Linux when I fancy doing some FPGA...

My old cheap-arse clone USB Blaster was STM32 based with a 8MHz crystal (red PCB). This new one is PIC18 and 12MHz crystal (green PCB).



Oh, and the dev board appears to work just fine 

[Macbeth]

Oh, for anyone interested in the documentation, schematics, and code for this board I have rehosted it on MEGA (NZ) because the Chinese guys link you get by email is really slow! I hope this works, it's quite big!

https://mega.nz/#!PI9wQAAK!h9lfFgYkCeyqfmOMDonJX90HvoenrujtsatB8H_a7co

[MagicSmoker]

Oh, for anyone interested in the documentation, schematics, and code for this board I have rehosted it on MEGA (NZ) because the Chinese guys link you get by email is really slow! I hope this works, it's quite big!
(url snipped)

Thanks for reporting on your experience and hosting the documentation; I'm buying one of these boards right now because of this.

[miguelvp]

164MB is not big at all

Thanks for posting.

Tempted although I have too many dev boards already. Too bad the VGA only has one bit per color. It wouldn't have cost them much to add a three bit per color R2R ladder.

[Macbeth]

I'm happy just to count some 7-segs and mess with a 1602 LCD for £24... That VGA voodoo is mind blowing to me... for now!

[MagicSmoker]

...
Thanks for reporting on your experience and hosting the documentation; I'm buying one of these boards right now because of this.

Well, so much for that... Aliexpress cancelled my order due to "insufficient documentation" but failed to tell me what documentation I needed. My credit card issuer says they didn't decline the charge so who knows what went wrong. This was my first, and it looks like it will be my last, experience with Aliexpress.

[Macbeth]

Bizarre!... But if you want to can the whole of China marketed via AliExpress all over a single fuck up with your one and only credit card issuer then so be it 

I think it goes without saying that Special Snowflakes need not try and deal with anything other than home grown stuff like Sparkfun!  ... and if really risking it, ebay, but don't tell Mom!

I will just say I have had some Ali sellers that have been scammers to say the least, but I knew I was entering the dragons den in those transactions AND GOT FULL REFUNDS.

This particular seller is A1 by all accounts. A little slow to get the stuff sent, but when it is it is fully tracked and takes about a month all in. That is pretty much par for the course with China.

[hamster_nz]

Well, so much for that... Aliexpress cancelled my order due to "insufficient documentation" but failed to tell me what documentation I needed. My credit card issuer says they didn't decline the charge so who knows what went wrong. This was my first, and it looks like it will be my last, experience with Aliexpress.

I've decided that I really do want an relatively inexpensive USB Blaster clone, and the board will be just a bonus, so ordered one. I'll let you know if I have any issues with my credit card...

[MagicSmoker]

Bizarre!... But if you want to can the whole of China marketed via AliExpress all over a single fuck up with your one and only credit card issuer then so be it 

I guess there is some truth to that old cliche about America and Britain being two countries separated by a common language... I said that the problem was NOT with my credit card issuer (they stated they never received a charge to decline, actually). Aliexpress sent me an email (the body of which is reprinted below) which was reminiscent of "Brazil" (the movie) or "Catch-22" (the book):

Thank you for shopping on AliExpress !

We are sorry to inform you that we have to cancel your order for security reasons. To make sure your transaction is secure, please provide us with documentation for further verification.

When we receive your documents, we will verify them within 3 business days. If the documents are valid, you can reorder on Aliexpress.

We apologize for any inconvenience, and thank you for your patience and understanding.

As you may note without me even prompting, nowhere does it say what "documentation" is necessary "for further verification." Furthermore, there is a line at the bottom of the email that says it was automatically generated and that replies to it will be ignored. THAT is why I am unlikely to place another order with them anytime soon. An FPGA development board is work related, and the way I see it, if I spend 30 minutes screwing around with Aliexpress (or writing posts about it here... ahem) then I just blew whatever money I theoretically saved vs. buying a legit board and USB Blaster from DigiKey, etc.

You picking up what I'm putting down now, compadre?

[Macbeth]

Did you happen to apply for an AliPay account? I seem to recall requiring documentation for that, but it shouldn't be needed. A straight credit card transaction should work just fine. I'm sure if you were ordering from Nigeria things would be different, but the USA should be just as easy as the UK for VISA or Mastercard. AMEX is another thing entirely if thats what you used. 

Oh, Brazil is one of my favourite movies  You wouldn't be a Mr Tuttle, sorry Buttle by chance? 

[bingo600]

I've bought quite a lot on Ali ,and never had a problem with my Visa Card.
I even feel i'm better protected there than on *bay/*Pal.

They don't release the money to the seller until you have confirmed that you have received your goods.

Just don't miss your "last protection" date, before you make a dispute/claim.

I have made 3 disputes, and have gotten my money back every time wo. any hazzle.


/Bingo

Ps:
The most annoying thing, is that they are often shipping via registered mail , and you have to go to the post office to pick it up.
Then again, it might even be an advantage getting it via registered mail or ....

[SpidersWeb]

Last night I ordered one of those $37 kits myself. Although afterwards I realized I kind of want one with some DRAM on board - so probably end up buying something else next year

No problems with Aliexpress payment here, but I've been using them for years so my details were all saved in etc etc

[MagicSmoker]

Did you happen to apply for an AliPay account? I seem to recall requiring documentation for that, but it shouldn't be needed. A straight credit card transaction should work just fine. I'm sure if you were ordering from Nigeria things would be different, but the USA should be just as easy as the UK for VISA or Mastercard. AMEX is another thing entirely if thats what you used. 

Nope, didn't apply for AliPay, didn't use an Amex. Poking around the site some more I did come across something about also verifying my business email, so I am trying that.

Oh, Brazil is one of my favourite movies  You wouldn't be a Mr Tuttle, sorry Buttle by chance? 

  More like Sam Lowry... But yeah, Brazil is one of my favorite movies of all time (along with Caddyshack and Airplane! - which probably says too much about me).

[MagicSmoker]

I decided to spring the extra $50 and get a DE0-Nano. It seems to be popular and looks like a good intro to working with FPGAs. I didn't get the one with the on-chip hard processor both because it seems you really overpay for that capability relative to a separate but equivalently powerful MCU, and I imagine it will just make the learning curve that much steeper, and at this stage in my career I am more into getting results rather than noodling around.

[Avien]

I decided to spring the extra $50 and get a DE0-Nano. It seems to be popular and looks like a good intro to working with FPGAs. I didn't get the one with the on-chip hard processor both because it seems you really overpay for that capability relative to a separate but equivalently powerful MCU, and I imagine it will just make the learning curve that much steeper, and at this stage in my career I am more into getting results rather than noodling around.

I have DE0-NANO and I have used it in my Master Thesis. Best thing about using Altera for start? Signal-TAP.
You can always implement NIOS II soft-cpu if you need and want to program something in C, but do not expect much from it (it only gets a job done). I have used F version with Scatter-Gatter DMA and it was road through hell. Also lovely Eclipse...
Now I would get SoC version with Ethernet (also "small" version). First it has much more logic inside, different LE, dual-core ARM and programmer for less than 100$? I know someone who buys those and put it inside products
Wish it only had more GPIO...

[ale500]

I also got one of those not that cheap Cyclone IV boards out of ebay, it came with the same USB Blaster clone as Macbeth mentioned, but the board is different:

http://www.ebay.de/itm/Altera-Cyclone-IV-FPGA-Learning-Board-EP4CE6E22C8N-mit-USB-Blaster-Programmer-/111832274825?hash=item1a09b91789:g:wPcAAOSwgyxWVGtq

Sadly, all pins are being used. The ones on the connector are the pins used for VGA  (16 bit color VGA!) plus the 2 PS/2 pins.

[Macbeth]

Sadly, all pins are being used. The ones on the connector and the VGA pins (16 bit VGA! Plus PS/2).

You've got J3 for GPIO?

Nicer board for the extra money. Some SDRAM, better VGA, proper FLASH, and an A/D for starters.

[ale500]

Yeah... but as I said (I corrected my post above, it seems I sopped mid sentence and continued with something else), J3 are the VGA/PS2 pins... I'd rather have the pushbuttons and 7-Segment display there... well

[justanothercanuck]

came across this playlist on youtube a couple weeks back...  sounds pretty good for a beginner (it starts from digital logic and goes from there)

https://www.youtube.com/playlist?list=PL7kkolCtIBKLukrBsEDwKRTE64JvaJDhM

[tggzzz]

came across this playlist on youtube a couple weeks back...  sounds pretty good for a beginner (it starts from digital logic and goes from there)
https://www.youtube.com/playlist?list=PL7kkolCtIBKLukrBsEDwKRTE64JvaJDhM

Does it discuss how to create timing constraints? If it was written then I could find out within 2 minutes, but since it is video I would have to spend a few hours looking for something that might not exist.

That's a bad use of my remaining life.

[Macbeth]

Does it discuss how to create timing constraints? If it was written then I could find out within 2 minutes, but since it is video I would have to spend a few hours looking for something that might not exist.

That's a bad use of my remaining life.

Yeah. A bit like going through all of Daves EEVblog vids. Only so many to watch before I shuffle off this mortal coil.

I just wish there was an internet search engine out there to help look for specific stuff?

[miguelvp]

Haven't watched the playlist but I did look at the actual playlist.

I think it's a good start and when someone tries them and have failures they hopefully look for extra information about timing constrains, but at least those videos could get someone started (I'm guessing because I didn't watch any of them yet)

[tggzzz]

I just wish there was an internet search engine out there to help look for specific stuff?

Good idea. I wish you hadn't mentioned it publicly, because now I can't patent it

[tggzzz]

I think it's a good start and when someone tries them and have failures they hopefully look for extra information about timing constrains, but at least those videos could get someone started (I'm guessing because I didn't watch any of them yet)

Many other things could also get them started. And if they are skimmable and searchable (e.g. text), then we could know they would be a good starting point.

There are good uses for video blogs, but too often they are done by someone that can't be bothered to spend the time to make life easy for their audience.

[miguelvp]

I think it's a good start and when someone tries them and have failures they hopefully look for extra information about timing constrains, but at least those videos could get someone started (I'm guessing because I didn't watch any of them yet)

Many other things could also get them started. And if they are skimmable and searchable (e.g. text), then we could know they would be a good starting point.

There are good uses for video blogs, but too often they are done by someone that can't be bothered to spend the time to make life easy for their audience.

Agreed, I'm partial to text myself:

https://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/

Then again it's up to the one imparting knowledge to figure out all the fall-outs, there are no shortcuts for those even if you went to the most credited school in the planet.

Guidelines are good, but we all have to figure the rest on our own.