how can I improve my code?

I suggest you could start with :

Your processes have many errors mentioned in this document.

process 1 : missing reset on lvds_clk process 2 : you use both edges of the clock ? (do you need this ?) process 3 : wrong sensitivity list, maybe not synthesizable depending on the target technology (asynchronous load), lvds_1_in is clocked by both edges and negatively clock enabled load_lvds ??

Bert Cuzeau

...and learn about 'case' statements. Syms.

Hi Bert,

thanks for looking at the code.

what do you mean by that? should I set lvds_clk to '0' during reset?

I think I need both edges, because there is no pause between two bytes, so the shift register needs to be loaded with the new data between the last and first bit. Or is there a better way (probably...)?

I have changed this process...

I have my new code attached. However I have read that case statements are better, because they can be implemented parallel... I will change that.

I have put the two processes that do the lvds_clk and the pixel counting into one process. Is it generally better to have one big process?

regards, Benjamin

-- lvds_tick is a clock at 7x pixel-clock (140 MHz)

-- lvds_clk is the clock for the lvds bus, same as pixel clock, but not symmetric

-- like this for one pixel period: --___-- process (lvds_tick,screen_reset) begin if screen_reset='1' then lvds_div

I take advantage of your post (and of the WeekEnd) for a question to the group.

I often see newbies writing things like :

case my_std_logic is when '0' =>

when '1' =>

when others => -- they HAVE to write this indeed !! end case;

They seem to believe it would be a better (more efficient !) style than : if my_std_logic='1' then else end if;

????? Since I've seen this a number of times, I'm curious to know who is telling them this ? and why ? a book ?

And when things get more complex, even more people seem to say that the case statement is a miracle... and would magically turn a "serial" computation into a "parallel" one, more efficient, that one has a priority while the other would not etc etc.... I usually hear the very same persons say they don't know what the '-' (don't care) is about !

I'm _not_ saying here that the case statement is never to be preferred, but the designer must be aware of the reality. The case statement in VHDL also has it's unfriendly sides (you often have to qualify the case expression like in "case A&B is" + there is also the locally static issue

• no way to use std_match in a case + case must be complete, etc...). The Verilog case statement, associated with parallel case pragma, is more versatile (like with a constant selector).

Even using the case statement (and don't cares), obtaining the minimal logic sometimes requires efforts (as for the one hot minimal decoder). My recommendation is to usually favor the style which provides the best expressiveness even at the (hypothetical) cost of a few gates.

I quickly wrote the example below. Note that I didn't merge the cases or the ifs so different decoding logic can easily be tested. It is also possible to remove some case(s) (thanks to the default statements).

Has anyone different views or experience to share ?

---------------------------------------------------------

-- Will the "case" statement really change your life :-) ?

--

-- Please let me know if there is one synthesis tool which

-- does provide a different QOR for the two architectures below.

-- I would use the case statement myself, but not in the

-- hope of better QOR.

library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all;

Entity casetest is port ( A : in std_logic_vector (3 downto 0); Q : out std_logic_vector (3 downto 0) -- MSB not used (= 0) ); end;

-- ------------------------------------ architecture RTL_case of casetest is

begin

process (A) begin case A is when x"0" =>

Q Q Q Q Q Q Q Q -- could use when others here Q Q Q Q Q Q Q Q Q

Hi Info,

I have read here, that case is more parallel:

regards, Benjamin

HI Bert,

Intersting topic to talk about ! .

I am a newbie(still at academic level) but I'll not accept from a book without saying why.

Here is the list which I have read ..... 1) RTL Implementaion Guide by Jack Marshall (from tera systems Inc). ( I got this from synopsys SNUG group,check it if u have account )

All say that case infers a parallel logic and if-elsif-else infers a proirity encoder structure ... If situation does'nt demand me for a prority logic Why shall I choose it ???

problem of qulifying expression has been addressed by vhdl committee and it is going be fixed soon.

completness of case is an advantage to find the bugs.Lets take an example.... Take the exmaple you mentioned above

Suppose my_std_logic is a conrol signal which must be initialized properly after reset. I cannot see that with your if - else code . but by having others clause I could watch all uninitialized 'U' signals by case statement.

I dont know partiuclarly about one hot minimal decoder but Synthesis tools say case statments are good for area opptimizations.

I dont think if-else provide more " expressiveness " then case. For parallel code case is more "expressiveness". At the end merits of hardware counts wheather it is in the form of few gates. Dont under estimate the number of gates as it is know causing more static power.

Thank you very much for starting such an interesting topic.

-- Mohammed A Khader.

They don't quite say this (or they'd lie). "If ... elseif" has an implied priority (first test true -> next tests are not taken)... but that makes no sense when you describe a truth table ! (as in my first encoder example) Whatever the means to describe behaviorally the truth table, it will end up the same, and by way of logic reduction it will lead to implementations that may or may not be similar depending on synthesis tools optimization goals, constraints, internal logic reduction algorithm, etc... Things may become different when complex operators are inferred. The BIG difference is that, from a synthesis perspective, describing a truth table isn't the same as describing higher level structures !

What I mean is be wary of general rules about synthesis. There are more than one tool, and tens of years of research behind them... I think it's pretty dangerous to say "this does infer that". Or you have to be damn accurate : given code snippet, given tool, given version, given technology, given constraints, etc etc

1. I didn't mean it was a problem ! You just need to know the language. Qualified expressions are just often unknown to newbies, but they are extremely useful. write (L,"hello"); for example. There's no problem in writing "case A&B" (a qualified expr does it). It's also possible to get directly the two MSBs of A + B (vectors). One just needs to know a bit more than the basics of VHDL.
2. What do you mean by "has been addressed..."? I don't want to start another controversy, but VHDL200X isn't out of the woods. We all just hope it will happen (out of IEEE and then into our tools) before the EDA community majority has switched to SystemVerilog. But there is absolutely no real need of a better VHDL for simple designs.

It's MUCH easier to follow good coding rules which ensure that the bad situation you mention will never happen in your design that trying to test every signal again 'U' ! If you want to do this, be consistent and write a test for every numeric vector, making sure it doesn't include any 'U'. Not cool.

Simple gross mistakes are easier to prevent than to detect.

I think this is the same with std_ulogic, which use was supposed to help detect multiple drivers situations (it did). But there are other ways to check this and so many other bad things are to be tested at synthesis that everybody has dropped now this unresolved type and obsolete style.

It's called hearsay I think. Then, why doesn't it show up in the simple examples I gave ? (XST 6.3.03i creates in fact a larger design with the "case" version)

I have reproduced below an old example that I sometimes used in my courses. I kept it simple minded (no fancy function). Why don't all synthesis tools give the simple OR gates ?

- The case version "looks" nicer, but check the gates count (with your tool).

- In the "if" solution : do you see a priority after synthesis ?? Chances are your synthesis tool will produce three times larger solution with the case than with the if. Don't believe ppt slides (nor me) !

1. How do you know you have "saved" some gates and achieved and an optimal solution ? What do you compare against ? In the example below, was 15 LUTs acceptable or not ? (without the comments saying it was not).
2. The case doesn't always produce less gates, sometimes the contrary as proved here. I try to not underestimate anything ! I just check by myself as much as I can and I encourage you, if you're sensitive to gate count and QOR, to always verify and never simply "assume".
3. If design could be made significantly smaller by avoiding "ifs", then don't you think the Synthesis tools would automatically do the translation internally ? (they do, this and many other tricks)
4. There is one or two orders of magnitude higher potential gain by smart implementation and good design know-how : being a smart architect pays !
5. Most synthesis tools are smarter and smarter, so a good understanding of your specific tool is also a good investment.
6. FPGAs and ASICs are two different worlds. What applies to one not necessarily applies to the other. Synthesizing to LUTs and to GATEs isn't the same. Don't forget Synopsys is an ASIC company. Driving DC ins't the same as doing FPGA synthesis.
7. Significant Power consumption reduction requires other techniques than using case instead of if (supposing that there is any gain at all doing so).
8. Gate count is definitely less and less an issue, even in the ASIC field ! Challenges have moved, and old books don't reflect this.

My experience is : Synthesis tools are often smarter than the designer thinks, but there are also sometimes doing some apparently "stupid" things (at least looking like such for unexperienced designers). Just try Q

"case" and "if then else" have no overlapping cases and therefore no priority.

"if then else elsif elsif ... " only implies priority if cases overlap.

I agree that std_ulogic_vector is usually more trouble than it's worth. However std_ulogic has no such downside. I use std_ulogic as my default bit type. It port maps directly to std_logic without conversion.

-- Mike Treseler

if A(7) = '1' then Q more trouble than it's worth.

Seems I was a bit too quick to burry std_ulogic...

I still won't use it, nor RTL procedures, but this is more a matter of habits and personal taste. I once suspected that you were using both as a hidden signature to copyright your code ;-)

Cheers,

Bert Cuzeau

I agree. Synthesis is free to make any netlist that sims like the code. I have found that coding style has a negligible effect on utilization for equivalent descriptions.

My point was that the logical idea of priority does not apply to all problems. Some are pieces of pie and some are Olympic rings.

Yes. It's a little like changing the spelling of my name on magazine subscriptions to see where it goes.

Hey howdy,

-- Mike Treseler

I need to add some more information to be absolutely accurate :

for rslt_idx in rslt'range loop for src_idx in src'length - 1 downto 0 loop if( ( ( src_idx / ( 2**rslt_idx ) ) MOD 2 ) = 1 ) then rslt( rslt_idx ) := rslt( rslt_idx ) OR src( src_idx + src'low ) ; end if ; end loop ; end loop ; return( rslt ) ; end ;

This function simply infers the OR gates directly ! In the case of this post, the one hot decoder ends up in three (4 inputs) LUTs, one logic layer instead of 2 (or more). I don't think there is any other description that infers the minimal result with all synthesis tools.

Bert Cuzeau

Info, The code above given by you for onehot did sysnthesize differently. the "case" version systhesized to 3 LUT's involving only OR gates and didnt infer priority structure infact it optimized as you have mentioned to a series of OR gates. But the "if" version systhesiszed to 6 LUT's and inferred a priority structure. Leonardo was used for the systhesis.

Hi Symon, for (most) of the given examples case and if-elsif will give the same result. Why? Because in both cases :-) your selector is fully covered (uses all of the bits of a vector or whatever you use as a selector). Your if-elsif collapses into a parallel structure, because there is no priority of one value over the other possible.

but how about this:

Selector Output Output Output Output 'Z'); end case;

vs.

If C = '1' then Output

Yes my point exactly. Not all tools do this correctly. Leoanrdo is right. Just try Precision Synthesis (or other tools) if you can and compare the results.

The if .. elsif is a priority encoder which has a well defined behavior for the overlapping cases (more than one 1 in the vector), and this requires more logic than the "pure one hot". This edscription is more predictible acroos tools.

Bert

Just a few errors :

1. you can in fact qualify the expression and not use a signal. A variable is usually preferable if you want one (otherwise, you must add Selector in your sensitivity list, and this slows down the simulation without usefulness).

case SLV3'(A&B&C) is -- with subtype SLV3 is std_logic_vector (3 downto 0);

1. output