«

Hi Everyone,

After stumbling upon Mike Treseler's UART design given in a previous post, I
eventually found myself at the following link:

http://www.designabstraction.co.uk/A...Techniques.htm

This is really interesting!!

I've read the links in this group that google shows for the URL above... But
i'd like more people's opinon on this approach: So, what are the thoughts of
comp.lang.vhdl on the ideas presented in this link, do you agree / disagree
the arguments given?

It concerns me the HDL written in this manner seams to be more like software
than hardware, i'm not really used to seeing and understanding code written
as in the RTL UART Example-But that's my own fault. The concept of single
process blocks is really fascinating, as to be frank, i'm guilty of making
my designs with many interlinked processes, indeed the knife and fork method
suggested.

Any thoughts anyone?

Thanks in advance.
Ben

Hi Ben,

> This is really interesting!!

My reply to Mike was "Beautiful!".

> I've read the links in this group that google shows for the URL above...
> But i'd like more people's opinon on this approach: So, what are the
> thoughts of comp.lang.vhdl on the ideas presented in this link, do you
> agree / disagree the arguments given?

Well, I personally think that the use of procedures and functions has been
taken to an extreme, but for some time now I'm designing state machines
using a process-local state variable instead of using a signal. This is
something I came up with myself a few months back while slightly drunk, but
I still liked it the next day, and I start liking it better and better.

One of the fun bits of this technique is that you can do your synchronous
assignments within the if rising_edge block, and your combinatorial
assignments outside the if statement. Very, very elegant.

> It concerns me the HDL written in this manner seams to be more like
> software than hardware, i'm not really used to seeing and understanding
> code written as in the RTL UART Example-But that's my own fault. The
> concept of single process blocks is really fascinating, as to be frank,
> i'm guilty of making my designs with many interlinked processes, indeed
> the knife and fork method suggested.

The many-processes method has the advantage of explicitly expressing latency
(i.e. the depth of your pipeline). Trouble with it is that VHDL dictates
the same boring preamble (process(clk,rst) blah blah, begin blah if rst=1
blah elsif rising_edge(clk) blah etc etc) for every process.

The stick-it-all-in-a-single-process method avoids all the preamble (thus
adding legibility to the whole thing) but has the disadvantage that you
need to really be aware of your pipeline depth.

I could ramble on about this for hours, but these will be my $.02 for today.

Best regards,

(another) Ben

Ben,

Do you have an example of the state-machine technique you describe that
you are willing to post? If so, I would like to see it.


Charles

Hi Charles,

> Do you have an example of the state-machine technique you describe that
> you are willing to post? If so, I would like to see it.

I just posted one example in the "advanced synthesis techniques" thread in
this group.

This PIDFilter.vhd file happens not to have any combinatorial logic in the
tail (between the "end if" and "end process") as I wanted all outputs of
this FSM to be registered, but you could for instance stick something like

...
end if;

rdy <= '1';
if bfind_state = SEARCHING then
rdy <= '0';
end if;
end process;

in there, instead of in the synchronous part. Precision, Synplify, and
Quartus will properly synthesize this. Don't know about ISE.

Best regards,


Ben

Hi Charles,

> Do you have an example of the state-machine technique you describe that
> you are willing to post? If so, I would like to see it.

Stupid me. It's in the "About hdl testbench" thread.

Best regards,


Ben