[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a VHDL puzzle
Hi,
I would like to make a comment on all responses to my email:
1. NO NATURAL, INHERENT STATEMENT STRUCTURES WITHIN vhdl ARE BUILT TO HANDLE
THE FOLLOWING THE MOST IMPORTANT AND MOST BASIC EQUATION in ABLE or AHDL:
OutBus <= a*ABus + b*BBus + c*CBus;
2. There are many ways to handle the situations either if you pay more logic
complexity to get above simple equation than ABLE or AHDL, or if you pay
extra gates for the simple logic. You cannot get both of them in VHDL, a
simple expression to get simple "AND" and "OR" equations.
3. So I strongly recommend (to whom?) that adding if-orif-endif structures
into VHDL is reasonable.
4. I couldn't get comp.lang.vhdl website. Is it wrong?
5. Why did I define VHDL as "VIRTUAL" Hardware Definition Language? Because
it ignores the most important and the most basic equations in its language
structure in hardware design REAL life.
Because it's not a suitable place to further discuss the VHDL issue, I will
not send any email to this address about the issue. But I welcome responses
directly to my personal email address.
Thank you.
Weng
----- Original Message -----
From: Kevin Normoyle <Kevin.Normoyle@Eng.Sun.COM>
To: <pci-sig@znyx.com>
Sent: Tuesday, January 23, 2001 12:21 PM
Subject: Re: Fw: a VHDL puzzle
> [snipped much detail about getting priority decoders in
> rtl, rather than muxes]
>
> > IT IS VERY NATURAL TO ME THAT vhdl SHOULD INCLUDE A STATEMENT STRUCTURE
> > TO GENERATE THE BASIC LOGIC EQUATIONS WITH MUTUALLY EXCLUSIVE CONDITIONS
> > FOR HARDWARE DESIGN: OR and AND EQUATIONS WITHOUT ANY HUSSLE.
>
>
> Yup. It's a big problem. Same thing with verilog.
> Lots of gates generated where they're not needed.
>
> Here's my favorite way to "do a reasonable thing" in verilog.
>
> Assume you have mutually exclusive selects (one-bit) A,B,C,D
> and they control 32 bit data onto a 32-bit output.
>
> Note, this will propagate X's correctly, unlike some
> other verilog behavioral code constructs.
>
> assign data[31:0] =
> (A==1'b1) ? (data_in_A[31:0] : 32'b0) |
> (B==1'b1) ? (data_in_B[31:0] : 32'b0) |
> (C==1'b1) ? (data_in_C[31:0] : 32'b0) |
> (D==1'b1) ? (data_in_D[31:0] : 32'b0) ;
>
> The control equations can be arbitrarily complex, if you don't have
> single bit contorl signals.
>
> Clumsy. But I share you pain at the rtl languages actually causing
> problems, rather than solving them.
>
> It usually pays to also have a monitor to check that the controls really
are
> exclusive.
>
> i.e.
>
> if (A + B + C + D !==1'b1) begin ....error message.... end
>
> This enforces one-hot-ness. Sometimes you don't need that...so you can do
>
> if ((A + B + C + D !==1'b1) & (A + B + C + D != 1'b0)) begin ....error
message.... end
>
> To just check "not more than one selected".
>
> Remember, we're not just talking about "synthesizing" with knownledge
> of mutually exclusivity, but we want the rtl to simulate logically like
> the final gate result. That's why use of case statements is rough in rtl,
> (first case is executed only).
> And nested if/else produces a priority encoder.
>
> A slightly different definition for "case" would have done the trick.
> But you really want both cases. :)
>
> -kevin
>
>
>