Author Topic: Beginner FPGA dev board  (Read 43689 times)

0 Members and 1 Guest are viewing this topic.

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #25 on: November 30, 2015, 08:28:01 am »
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
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline 1uk3

  • Contributor
  • Posts: 22
  • Country: at
Re: Beginner FPGA dev board
« Reply #26 on: November 30, 2015, 08:45:58 am »
Did you try this fix http://help.ece.ubc.ca/Altera? (scroll down)
I think i used 13.0 on a Win8.1 machine.
 

Offline obiwanjacobiTopic starter

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #27 on: November 30, 2015, 10:14:20 am »
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  ;D
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #28 on: November 30, 2015, 10:50:00 am »
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.

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

There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 649
  • Country: au
Re: Beginner FPGA dev board
« Reply #29 on: November 30, 2015, 11:06:43 am »
Was that list from hamster what C could manage? or just syllabus from a Uni fpga course?
 

Offline Moondeck

  • Regular Contributor
  • *
  • Posts: 142
  • Country: dk
  • i really like compilers
Re: Beginner FPGA dev board
« Reply #30 on: November 30, 2015, 04:10:06 pm »
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
I'm selling 100ml bottles of free energy, PM me for pricing.
 

Offline obiwanjacobiTopic starter

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #31 on: November 30, 2015, 05:07:50 pm »
In the logs I saw:
Quote
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 ...   :P



Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #32 on: December 01, 2015, 04:05:07 pm »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #33 on: December 01, 2015, 05:06:59 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #34 on: December 01, 2015, 06:07:26 pm »
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.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline 1uk3

  • Contributor
  • Posts: 22
  • Country: at
Re: Beginner FPGA dev board
« Reply #35 on: December 02, 2015, 09:29:40 am »
Quote
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #36 on: December 02, 2015, 10:07:55 am »
Quote
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline obiwanjacobiTopic starter

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #37 on: December 03, 2015, 07:34:48 am »
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...
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4509
  • Country: au
    • send complaints here
Re: Beginner FPGA dev board
« Reply #38 on: December 03, 2015, 10:52:07 am »
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 :)

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

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #39 on: December 03, 2015, 11:20:56 am »
Quote
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Beginner FPGA dev board
« Reply #40 on: December 03, 2015, 12:48:39 pm »
Quote
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 !  :-DD

 

Offline obiwanjacobiTopic starter

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #41 on: December 03, 2015, 01:29:29 pm »
"There's nothing you cannot fix with another level of indirection"  >:D
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #42 on: December 03, 2015, 01:54:03 pm »
"There's nothing you cannot fix with another level of indirection"  >:D

The signal processing equivalent is "all problems can be solved by integrating for longer" :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #43 on: December 03, 2015, 06:55:34 pm »
Quote
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 !  :-DD

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

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #44 on: December 03, 2015, 08:55:35 pm »
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.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #45 on: December 04, 2015, 02:31:23 am »
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"!
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #46 on: December 04, 2015, 03:59:57 am »
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!
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #47 on: December 04, 2015, 10:04:59 am »
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.

Quote
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline obiwanjacobiTopic starter

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #48 on: December 04, 2015, 10:44:35 am »
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  :-DD
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #49 on: December 04, 2015, 11:03:50 am »
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  :-DD

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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf