Why does it require a register?  Yes it has to be
in a process, but the process can be one sensitive to the
mux inputs rather than to clock.  You can also use the switch statement instead, which is
a concurrent
equivalent to the case.

Matthew E Rosenthal wrote:

> When trying to create a mux with a case statement XST requires the output
> be a reg.  Why is this and would making it a reg(latch) make the mux
> slower?
>
> Matt

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

"Matthew E Rosenthal"
<m...@andrew.cmu.edu> wrote in message
news:P...@unix3.andrew.cmu.edu...
> When trying to create a mux with a case statement XST requires the output
> be a reg.  Why is this and would making it a reg(latch) make the mux
> slower?
>
> Matt

When trying to create a mux with a case statement VERILOG requires the use
of reg elements.  These do not have to end up as registers and will not slow
the design.  Assemble the case statement inside an always block with all the
inputs in the sensitivity list.  The resulting "reg" values assigned in the
case statement are effectively wires.

- John_H

Hi - 

On Thu, 8 Apr 2004 02:05:30 -0400 (EDT), Matthew E Rosenthal
<m...@andrew.cmu.edu> wrote:

>When trying to create a mux with a case statement XST requires the output
>be a reg.  Why is this and would making it a reg(latch) make the mux
>slower?

Declaring something "reg" does *not* necessarily mean that it will be
syntheized or simulated as a register or latch.  The 1364-2001 spec
says:

"Assignments to a reg are made by procedural assignments (see 6.2 and
9.2). Since the reg holds a value between assignments, it can be used
to model hardware registers. Edge-sensitive (i.e., flip-flops) and
level sensitive (i.e., RS and transparent latches) storage elements
can be modeled. A reg needs not represent a hardware storage element
since it can also be used to represent combinatorial logic."

Instead of "reg," think "sticky."  (But type "reg"!)

Bob Perlman
Cambrian Design Works

>Matt
>
>On Thu, 8 Apr 2004, rickman wrote:
>
>> john jakson wrote:
>> >
>> > "John Adair" <n...@loseinspace.co.uk> wrote in message
news:<XVOcc.2$b...@newsr2.u-net.net>...
>> > > Usually your best chance of getting it is with a CASE statement.  No
>> > > guarantees though as synthesisers are notoriously unpredictable.
>> > >
>> > > You can also try structuring your VHDL to suggest a element layout.
>> > >
>> > > Instantiating macros in your HDL will give you a more exact structure.
>> > >
>> > > --
>> > > John Adair
>> > > Enterpoint Ltd.
>> > > http://www.enterpoint.co.uk
>> > >
>> > > This message is the personal opinion of the sender and not that
necessarily
>> > > that of Enterpoint Ltd.. Readers should make their own evaluation of
the
>> > > facts. No responsibility for error or inaccuracy is accepted.
>> > >
>> > >
>> > > "Matthew E Rosenthal" <m...@andrew.cmu.edu> wrote in
message
>> > > news:P...@unix3.andrew.cmu.edu...
>> > > > I am trying to get XST to infer an 8:1 or even a 4:1 mux, instead
of using
>> > > > several 2:1 muxs'.
>> > > > Is there a suggested coding style to get xst to infer the larger
muxes or
>> > > > how would i hardcode them to make larger muxes?
>> > > >
>> > > > Thanks
>> > > >
>> > > > Matt
>> >
>> > look in the XST templates.
>> >
>> > In Verilog
>> >
>> > x <=
>> > (sel==0)? a0 :
>> > (sel==1)? a1 :
>> > (sel==2)? a2 :
>> > (sel==3)? a3 :
>> >           an
>> >
>> > and so on works for me. I've gone to 8 no problem. But occasional use
>> > of hardcoding a MUXxyz can help to build the top stage if you need to
>> > combine say a 2->1 with an earlier 4->1 and so on. There are quite a
>> > few app nots in the xapp dir.
>>
>>
>> I have not tried coding this in XST, but I am pretty sure it does not
>> result in an 8:1 mux.  The syntax you show is a priority selector.  That
>> means that it indicates an order of precedence.  Even though it makes no
>> difference since the selectors in each case are mutually exclusive, it
>> is unlikely that this will be optimized to a proper mux.
>>
>> The recommended coding style would be a case statement, which by
>> definition has mutually exclusive selections of a single control
>> variable.
>>
>> A better coding method for bus muxes would be to pre-decode the
>> selectors so that each of the 8 mux inputs has a separate enable.  Then
>> an 8 input mux can be done in just two levels of LUTs.  The first level
>> can encode the AND gates and one OR gate for combining two inputs.  The
>> second level is an four input OR gate for the final output.
>>
>> --
>>
>> Rick "rickman" Collins
>>
>> r...@XYarius.com
>> Ignore the reply address. To email me use the above address with the XY
>> removed.
>>
>> Arius - A Signal Processing Solutions Company
>> Specializing in DSP and FPGA design      URL http://www.arius.com
>> 4 King Ave                               301-682-7772 Voice
>> Frederick, MD 21701-3110                 301-682-7666 FAX
>>

Ray,
OK, I'll grant that in special cases there are other possible structures.
#2 sounds a little weird, like self-modifying code.  Don't forget #5:  one
can set the contents of a blockRAM so that the address lines can be used for
mux control and data.
-Kevin

"Ray Andraka" <r...@andraka.com> wrote in message
news:4...@andraka.com...
> Well, there are a few ways I can think of:
>
> 1) Use TBUFs to wire-OR LUT outputs together
> 2) Use the OR cascade in virtexII in the same way, preferable because it
is
> faster and more plentiful
> 3) If you can accept a 16 clock set-up time, you can use the SRL16 as a
> programmable LUT.  The programmer uses 2.5 slices, and loads up the SRL16
(or a
> word wide bank of them) with the appropriate pattern to connect the
selected
> input to the output ( patterns are for a mux with enable are
>
X"0000",X"AAAA",X"CCCC",X"F0F0",X"FF00")
.  This is useful for minimum
> propagation time 4:1 muxes for applications where the selection is
relatively
> static, or is otherwise allowed time to complete.  Yes, I have used it.
> 4) if your sources to the mux have available terms or come from
flip-flops, you
> can substitute a 4 input OR for each MUX bit by having your select logic
gate
> off all but one of the inputs at any given time.  If the inputs are from
> flip-flops, you can use the sync reset on the flip-flops for the gate
function
> without having to add logic in front of the flip-flop other than the
decoder on
> the reset.
>
>
>
>
> Kevin Neilson wrote:
>
> > "Matthew E Rosenthal" <m...@andrew.cmu.edu> wrote in message
> > news:P...@unix3.andrew.cmu.edu...
> > > I am trying to get XST to infer an 8:1 or even a 4:1 mux, instead of
using
> > > several 2:1 muxs'.
> > > Is there a suggested coding style to get xst to infer the larger muxes
or
> > > how would i hardcode them to make larger muxes?
> > >
> > > Thanks
> > >
> > > Matt
> >
> > I don't understand how you would make a 4:1 mux in a Xilinx without
making
> > it out of smaller muxes.  The LUTs only have 4 inputs, so you can't make
a
> > 4:1 mux out of a single LUT.  You need two LUTs plus another F5 mux.
> > -Kevin
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email r...@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>

Kevin, I presume you meant to say #3, not #2
'sounds a little weird.  #2 is very
straight forward, and not much different than #1 or #4.  #3 is more like a poor
man's reconfiguration of only the LUTs involved.  I suppose you can call it self
modifying, but it only modifies specific LUTs with one of 5 specific sets of
bits.  The fact is, it gets you a 4:1 mux in one level of LUTs, and it is
spacewise efficient for word-wide data paths.

Kevin Neilson wrote:

> Ray,
> OK, I'll grant that in special cases there are other possible structures.
> #2 sounds a little weird, like self-modifying code.  Don't forget #5:  one
> can set the contents of a blockRAM so that the address lines can be used for
> mux control and data.
> -Kevin
>
> "Ray Andraka" <r...@andraka.com> wrote in message
> news:4...@andraka.com...
> > Well, there are a few ways I can think of:
> >
> > 1) Use TBUFs to wire-OR LUT outputs together
> > 2) Use the OR cascade in virtexII in the same way, preferable because it
> is
> > faster and more plentiful
> > 3) If you can accept a 16 clock set-up time, you can use the SRL16 as a
> > programmable LUT.  The programmer uses 2.5 slices, and loads up the SRL16
> (or a
> > word wide bank of them) with the appropriate pattern to connect the
> selected
> > input to the output ( patterns are for a mux with enable are
> >
X"0000",X"AAAA",X"CCCC",X"F0F0",X"FF00")
.  This is useful for minimum
> > propagation time 4:1 muxes for applications where the selection is
> relatively
> > static, or is otherwise allowed time to complete.  Yes, I have used it.
> > 4) if your sources to the mux have available terms or come from
> flip-flops, you
> > can substitute a 4 input OR for each MUX bit by having your select logic
> gate
> > off all but one of the inputs at any given time.  If the inputs are from
> > flip-flops, you can use the sync reset on the flip-flops for the gate
> function
> > without having to add logic in front of the flip-flop other than the
> decoder on
> > the reset.
> >
> >--

--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

rickman  wrote

> john jakson wrote:

snipping

> > 
> > look in the XST templates.
> > 
> > In Verilog
> > 
> > x <=
> > (sel==0)? a0 :
> > (sel==1)? a1 :
> > (sel==2)? a2 :
> > (sel==3)? a3 :
> >           an
> > 
> > and so on works for me. I've gone to 8 no problem. But occasional use
> > of hardcoding a MUXxyz can help to build the top stage if you need to
> > combine say a 2->1 with an earlier 4->1 and so on. There are quite a
> > few app nots in the xapp dir.
> 
> 
> I have not tried coding this in XST, but I am pretty sure it does not
> result in an 8:1 mux.  The syntax you show is a priority selector.  That
> means that it indicates an order of precedence.  Even though it makes no
> difference since the selectors in each case are mutually exclusive, it
> is unlikely that this will be optimized to a proper mux.  
> 

I did miss 1 detail, I use the form in both cont = assignments and the
always <= form but only if the output isn't needed elsewhere before
the DFF.

Technically it is a priority encoding, but since the sel values are
unique, the result is always a mux. In the report and layout I see all
the muxes I expect to see except when the inputs are coded as
constants in which case the mux is smaller. I have actually used alot
of 4->1s which is a pair of LUTs locked. The 8->1 mux (actually 7->1
with the extra 0) used for status flag selection uses a pair of 4->1
with the extra MUXFx as it says in the appnotes. The hidden MUXF567
supposedely are much faster than extra LUT 2->1 so an 8->1 is really 4
2->1 LUTs with 3 more MUXF cells so delay may be much faster than
binary treee of LUTs. At least all the reports and docs leads me to
believe this.

I am actually quite impressed with XST so far, I have't really had to
instance any primitives except the Blockram to get true dualport R &
W.


> The recommended coding style would be a case statement, which by
> definition has mutually exclusive selections of a single control
> variable.  
> 
> A better coding method for bus muxes would be to pre-decode the
> selectors so that each of the 8 mux inputs has a separate enable.  Then
> an 8 input mux can be done in just two levels of LUTs.  The first level
> can encode the AND gates and one OR gate for combining two inputs.  The
> second level is an four input OR gate for the final output.  
> 


Thanks for reminding me of And/Or, there may be occasions where I just
might need that trick. So far I have used MUXF5,6s for some sneek
paths, then rewrote the whole module to do better job without.

regards

johnjakson_usa_com

Ray,
I'm sure it's a valuable design technique.  I think it just reminded me of
the meta-FPGA which worked in a similar fashion.  Some guy made a meta-FPGA
that sat on top of a Xilinx.  You'd load his meta-FPGA, which had all the
SRLs connected together in a big JTAG-like chain, and then you could program
the meta-FPGA with your own design by loading a serial stream into all the
LUTs.  Some LUTs were used as LUTs and some for routing.  I can't remember
exactly why it was useful except that you could write your own open-source
router, which apparently was an appealing prospect to somebody.
-Kevin

"Ray Andraka" <r...@andraka.com> wrote in message
news:4...@andraka.com...
> Kevin, I presume you meant to say #3, not #2 'sounds a little weird.  #2
is very
> straight forward, and not much different than #1 or #4.  #3 is more like a
poor
> man's reconfiguration of only the LUTs involved.  I suppose you can call
it self
> modifying, but it only modifies specific LUTs with one of 5 specific sets
of
> bits.  The fact is, it gets you a 4:1 mux in one level of LUTs, and it is
> spacewise efficient for word-wide data paths.
>
> Kevin Neilson wrote:
>
> > Ray,
> > OK, I'll grant that in special cases there are other possible
structures.
> > #2 sounds a little weird, like self-modifying code.  Don't forget #5:
one
> > can set the contents of a blockRAM so that the address lines can be used
for
> > mux control and data.
> > -Kevin
> >