RE: a VHDL puzzle

[Tom Curran <tom_curran@memecdesign.com>]

Please take this thread offline or somewhere else (perhaps the VHDL news
group?).

This is not the proper forum for your VHDL-bashing drivel.

Regards,
Tom


> -----Original Message-----
> From: Weng Tianxiang [mailto:wtx@umem.com]
> Sent: Tuesday, January 23, 2001 2:13 PM
> To: pci-sig@znyx.com
> Subject: 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
> >
> >
> >
> 
>