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.
Did you try this fix http://help.ece.ubc.ca/Altera? (scroll down)
I think i used 13.0 on a Win8.1 machine.
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..?
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.
Script stderr: Qt: Untested Windows version 6.2 detected!
Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines
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.
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.
with a much-improved mental model of what I was doing from then on
Quotewith a much-improved mental model of what I was doing from then onI think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.
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)
Quotewith a much-improved mental model of what I was doing from then onI 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.
Quotewith a much-improved mental model of what I was doing from then onI 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.
I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.
"There's nothing you cannot fix with another level of indirection"
QuoteI 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 !
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)
colour <= palette(to_integer(unsigned(iterations_in)));
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.
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"!
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!
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