In my first blog here on All Programmable Planet (APP), I called the analogies between HDL design and software development "obvious and beautiful." From this observation, I suggested that a "software perspective" would be very useful for certain HDL design tasks.
My goal with this column is to put this idea into practice at the RTL level.
As a example, I chose a Gray counter that uses the Gray code word itself as the state. This design has been discussed on APP before, and Altera has published Verilog and VHDL solutions. However, I think we can do better...
The algorithm
The first task is to develop an algorithm. Recall that successive words in a Gray count sequence differ by only a single bit. The purpose of the algorithm is thus to find which bit to toggle for any given Gray code word. Let's consider the first steps in a 4-bit Gray count sequence as follows:
For even steps, the bit to toggle is always the LSB (least-significant bit) at position 0. As a single bit changes at each step, the corresponding words share a common property: even parity. This part of the algorithm is easy enough: for even parity words, toggle the LDB.
For odd steps, the solution is a little more complex. It turns out that you have to find the first 1 in the word, starting from the LSB. The bit to toggle is located at the next higher position.
The remaining problem is to combine even and odd steps in one algorithm. The idea I had is to construct a new word by shifting the Gray code word one bit to the left. For odd steps, the first 1 in that word gives you the exact position to toggle. Moreover, the LSB position is now vacant. If you put the even parity bit in there, the first 1 in the word should give you the position to toggle for all cases.
This works fine, except for Gray code word "1000." If you shift this word to the left, all the 1s are gone, so we don't know what position to toggle. Upon inspection, this word should be followed by "0000." Therefore, the solution is to set the msb of the shifted word unconditionally to 1 as a fallback solution.
This means that our final algorithm is as follows: Given an n-bit Gray code word G = { g[n-1] g[n-2] g[n-3] ... g[0] }, with g[k] representing the individual bits of the word:
Construct a new word W = { 1 g[n-3] ... g[0] p }, with 'p' being the even parity bit of G.
Starting from the LSB at position 0, look for the first 1 in W
Toggle the bit in G at the corresponding position.
jandecaluwe 2/15/2013 3:03:23 PM User Rank Blogger
Re: Without Compare...
@a1js "Otherwise, the idea of equal support for unequal target languages leads inescapbly to the lowest common denominator in terms of usable capabilities of the source language."
Not necessarily, because the MyHDL convertor actually does "a little synthesis of its own".
Normally I don't call it synthesis because the convertor doesn't change the abstraction level. However, it does support useful abstractions that are not natively supported by Verilog, or VHDL, or both.
One set of abstractions comes "for free" as the Python interpreter is used to elaborate the design. For example: structural recursion. See this example. I wouldn't know how to do this in Verilog natively.
Another set are native MyHDL abstractions that the convertor supports. Examples:
intbv - hardware friendly integer-like type without limits on the range (unlike VHDL)
modbv - modular type for modulo arithmetic (borrowed from Ada (!))
@always_seq - process that infers the reset structure automatically
"I will try to explain briefly how MyHDL conversion works, I think this should address most of your questions."
Jan,
Thanks for the explanation. I understand your motivations. The choice to convert an elaborated instance, rather than the myHDL source itself, is certainly much easier.
But it also distorts the comparison between the languages, especially if the converted code is used (whether intended or not) as the basis of the comparison.
I agree whole-heartedly that verilog needs a lot more help in abstraction than does VHDL. But that alsomeans additional accommodations (conversion effort) are due. Otherwise, the idea of equal support for unequal target languages leads inescapbly to the lowest common denominator in terms of usable capabilities of the source language.
@aj1s "Secondly, the use of the "found" variable is not necessary... Not using an exit statement misses another opportunity to illustrate your point."
No, here you are jumping to conclusions too fast.
Apart from checking whether the experts are awake :-), I have 3 good reasons not to use an exit condition in this post. They are not related to my personal preferences or inherent restrictions from Python, MyHDL conversion, or Verilog.
The first reason is that I'm following a step-by-step approach, as I explained elsewhere. "found" demonstrates that a variable can meaningfully take different values during a single clock cycle evaluation. To those unfamiliar with using variables in synthesizable code, that's an important message.
The second reason is Verilog related: exit conditions can be done, but result in ugly workaround code involving named loops and disable statements. It is an excellent illustration of how MyHDL conversion can make it easier to write code, but that is all.
The third (blocking) limitation is that while such Verilog code above is perfectly synthesizable and I've never known it otherwise, it turns out that Xilinx ISE doesn't accept it. (Quartus does.) Imagine the damage to the central message if I would have posted this code and then it turned out that "it was not synthesizable"...
Point 2 and 3 may be useful in future posts, once I'm sure that the message in the present column is understood.
@Andy "First, it appears that the conversion process from myHDL to verilog/VHDL does a little synthesis on its own."
I will try to explain briefly how MyHDL conversion works, I think this should address most of your questions.
In a MyHDL flow, VHDL/Verilog are used as a back-end format. The conversion goals are as follows:
1) as easy as possible 2) same level of support for both Verilog/VHDL 3) readibility counts to trace back issues
From 1) follows the idea to maximally use the Python interpreter itself. In particular, the convertor doesn't start from source, but from an elaborated instance. As as a side effect, this gives amazing power, because any conversion restriction only applies to code inside processes. Embedded Python scripting comes for free ...
2) means that indeed, there are compromises because I want equal support for the two. MyHDL is more urgent for Verilog users :-)
3) means that I try to make code readable - however because of 1) it is certainly not how I would write VHDL manually. In particular, the type mapping is done in such a way to make conversion as easy as possible.
@Jezmo "Jan I've never been called conventional before I'll have to tell them at work they'll laugh"
Let me be precise. You are a good reference whenever someone thinks that I am exaggerating about the absurdities of the "conventional wisdom" in HDL design.
@jezmo I don't think you are giving most folks here credit, These are seasoned engineers with a fair amount of design experience and they are providing interesting topics to ponder. If we have the tools at our disposal we might as well use them. Having good examples which work (as Jan provides) and which don't is very valuable.
Noone appears to be under the illusion that magically, if you write software for a Von Neumann type computer working hardware will emerge from thin air. Rather constructive convesations are being presented which *software* techniques can enhance a designers effectiveness and quality.
@Gracia and @jan. Thanks! The page does need updating there have been some nice enhancements to MyHDL since I originally posted the page. Updating the CIC example would be a worthwhile activity.
@Goran HDL is the tool, it is like math. Just knowing math (or the math) doesn't fully help an engineer. You need to know what problem(s) you are solving and/or what you are designing. As Jan eludes in the post, you need to be hardware aware, know which levels of abstraction assist, intimate with the tools, and not stuck on old clichés.
Sounds like we are in good company!
The /Yo-Yo/ analogy is interesting, good tools allow the designer to access and evaluate the different levels of representation. It does seem like many designers get their /Yo-Yo/ stuck "walking the dog" and forget to come out of the low-level abyss.
@Gracia- Thanks! I participate in the APP conversations from time to time. I have been having a ton of fun with MyHDL. Now I just need to figure out how to allocate more time for MyHDL designs!
Until a few weeks ago, I knew next to nothing about cellular automata. Therefore, my first step was to try to discover as much as possible as quickly as possible about this application domain.
Why don't we make a little modeling contest out of this? Given a width 'n,' write a reference model in Verilog or VHDL that returns the corresponding Gray code in a representation of your choice...
VHDL and Verilog have served us exceptionally well, but they also have significant issues. In order to realize the full potential of HDL design, we need a better HDL. In this blog, the creator of MyHDL -- Jan Decaluwe -- considers the concept of signal assignments.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
