To understand the possibility of the fact that 'programming' an FPGA could be actually easier that 'programming' a microprocessor, we must understand the subtly that we actually don't 'program' an FPGA at all, we just configure it. There is no 'instruction set', so we are not creating instructions. FPGAs contain a fixed set of hardware resources, so our job is just to configure those resources in such a way that gives us something useful. With SpeakHDL, we try to drive that point home. The point is, that we 'assume' you have the hardware resource, our job is just to configure it.
When we say 'configure counter', that is literally the idea.
<picture of counter?>
With our Flat Fixed Port Flat Architecture, what we have essentially created is a intermediate configuration. That is, a way to logically organize design files, and logical organize 'procedure' parameters in such a way that that a synthesizer will give us a useful final 'configuration.' We hide complexity by offering the user a more familiar interface in which to parameterize the fpga with procedure calls that offer good semantics.
If we are configuring a device and not programming one, almost naturally we shouldn't care as much a bout syntax. At the end, we were looking to try to get to some description ultimately that some synthesis tool understands to 'wire up' the FPGA.
There seems to be a general consensus that writing code that operates in parallel such as is 'harder' that writing code that operates sequentially such as a software program. With parallel procedural programming with SpeakHDL, this is not the case. In actuality, it is the parallel nature of the FPGAs that makes them much easier to program, and what makes voice configuration useful. The reason for this is that
in general
, the order of the commands do not matter.
Whether we use a text editor or use a drag and drop tool, for productivity, what we have essentially is some code in the background running. If the code is useful, the code should try to infer what the user would most likely would want and do some things in the background to make the experience better for the user.
When dealing with voice commands, we get the opportunity to run a function based on what the user says. That means we have an opportunity for parameter checking, and moving things around to create the 'uniform style for VHDL code'.
<this is really prevalent when doing write data by opening the channel>
When we say a voice command and have our text editor updated, we wish to have the procedure in a form that is useful. That is we would like it to return in a form that will compile, and synthesize as a default. In addition, we since wa have a choice as to what to make the default parameters, we would liek to have it in a form that gives is the most clue what is happening if there is a bug in our code.
We like for counters to be enabled by default. write fifo data, has some 1's and zeros, and one can see it is not flat lined.