Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Ads

Discussion Groups

Discussion Groups | FPGA-CPU | Re: arithmetic

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

arithmetic - Rob Finch - Feb 26 16:57:00 2005


Has anyone noticed that it's almost as efficient to use sign-
magnitude arithmetic on an FPGA as it is to use two's complement
arithmetic ? I've been thinking about going this route because it
makes some operations easier. Rob





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )


Re: arithmetic - Ben Franchuk - Feb 26 18:19:00 2005

Rob Finch wrote:
>
> Has anyone noticed that it's almost as efficient to use sign-
> magnitude arithmetic on an FPGA as it is to use two's complement
> arithmetic ? I've been thinking about going this route because it
> makes some operations easier.
> Rob
I thought you have to recompilment if you get a negitive result
with sign magnitude math. That is a extra cycle. Also +- 0's can
be a problem. http://www.fourmilab.ch/documents/univac/index.html
Check here for ideas, but I have not heard of a computer doing
sign magnitude math.
Ben alias woodelf



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: 16f819 question - rtstofer - Feb 28 0:00:00 2005



The usual way to do this is to keep a variable in RAM representing
the output bits. Modify this variable and then send the variable to
the port as an entire byte.

I don\'t know anything about PicBasic but there is a read-modify-
write issue with PICs that is well documented in the various
datasheets. It is not a problem, it is just an issue. Particularly
when some bits change from input to output and back.

--- In , "meriachee" <meriachee@y...> wrote:
>
> I am using the PicBasic compiler to do some experimentation with
the
> PicMicro 16f819 chip. The book says that when you use the poke
> command to change PortA, you change ALL of the ports (input or
> output).
>
> I want to use these ports to drive bi-colour leds, don\'t much care
> about reading the status of the ports, but would just like to set
the
> pin(s) to high or low, PER pin, not the whole block... The data
sheet
> does not seem to be much help, and the frustration level is
growing
> wildly. (Ignorance is not always bliss!)
>
> Can somebody who is more enlightened than I, tell me how to set
> individually, the available pins in the PortA block of the 16f819,
to
> either high or low. The rest is easy...
>
> Thanks
>
> Gary





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: arithmetic - Perez Ramas, Javier Basilio - Feb 28 12:06:00 2005


You need additional logic in order to calculate the sign and that represents area in your design. Exactly, in what kind of operations are you thinking? Is the simplification of the math enough to justify this?

Best regards,

Javier

> -----Mensaje original-----
> De: Ben Franchuk [mailto:]
> Enviado el: sábado, 26 de febrero de 2005 23:19
> Para:
> Asunto: Re: [fpga-cpu] arithmetic >
> Rob Finch wrote:
> >
> > Has anyone noticed that it's almost as efficient to use sign-
> > magnitude arithmetic on an FPGA as it is to use two's complement
> > arithmetic ? I've been thinking about going this route because it
> > makes some operations easier.
> > Rob
> I thought you have to recompilment if you get a negitive result
> with sign magnitude math. That is a extra cycle. Also +- 0's can
> be a problem. http://www.fourmilab.ch/documents/univac/index.html
> Check here for ideas, but I have not heard of a computer doing
> sign magnitude math.
> Ben alias woodelf >
> To post a message, send it to:
> To unsubscribe, send a blank message to:
>
> Yahoo! Groups Links




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: arithmetic - Rob Finch - Feb 28 17:26:00 2005


--- In , "Perez Ramas, Javier Basilio"
<jbpramas@i...> wrote:
>
> You need additional logic in order to calculate the sign and
>that represents area in your design. Exactly, in what kind of
>operations are you thinking? Is the simplification of the math
>enough to justify this?

Actually, it doesn't really require any more logic / area than would
be required for two's complement arithmetic. It's only a single LUT -
two's complement arithmetic requires the same resources.

Here is some sample code I did to check out size and performance.
(I'm not sure this code actually works, I just wanted a rough idea of
how things might work). It's not as good as a two complement addsub
but this has more to do with the synthesizer than whether or not it
consumes more resources in an FPGA. It should be possible to code the
addsub so that it uses roughly the same resources as for two's
complement.

The key to this is that four-to-one muxes can be implemented for the
same cost as two-to-one muxes in an FPGA. So it's I think it's
possible to sort the operands for a subtract at little additional
cost.

A normal addsub would have a test like 'op ? a + b : a - b;' This is
a two-to-one mux. The four-to-one mux doesn't (or shouldn't) take any
more resources in the fpga.

Note the agtb comparison does use up resources that a normal adder
wouldn't. However this comparison is used elsewhere in the design, so
I could feed it in as another signal. Other than that it only takes
an extra LUT for flipping the operation (add or sub) around based on
the signs.

If this had to be done using discrete logic it would take double or
triple the resources, which is probably why sm isn't used nowadays;
but this is fpga-world where strange things happen.

I wonder if there might be problems implementing the carry chain....

I like sign-magnitude arithmetic because it's easy to understand.

module sm_addsub(op, ci, a, b, o, co);
parameter DBW = 32;
localparam DMSB = DBW-1;
input op; // 0 = add, 1 = sub
input ci;
input [DMSB:0] a;
input [DMSB:0] b;
output [DMSB:0] o;
output co;

// some aliases
wire sa = a[DMSB]; // sign of a
wire sb = b[DMSB]; // sign of b
wire [DMSB-1:0] ma = a[DMSB-1:0]; // magnitude of a
wire [DMSB-1:0] mb = b[DMSB-1:0]; // magnitude of b
wire op2 = sa ^ sb ^ op;
wire agtb = ma > mb;
reg [DMSB:0] o1;
reg so; // sign of output

always @(op2 or agtb or ma or mb or ci)
case ({op2,agtb})
2'd0: o1 <= ma + mb + ci;
2'd1: o1 <= ma + mb + ci;
2'd2: o1 <= mb - ma - ci;
2'd3: o1 <= ma - mb - ci;
endcase

// results sign
always @(op2 or agtb or sa or sb)
case ({op2,agtb})
2'd0: so <= sb; // signs are same, add
2'd1: so <= sa; // sign are same, sub
2'd2: so <= sb; // sub: b > a ? sb
2'd3: so <= sa; // sub: a > b ? sa
endcase

assign co = o1[DMSB];
assign o = {so,o1[DMSB:1]};

endmodule



Re: arithmetic
Re: arithmetic


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: arithmetic - Kolja Sulimma - Feb 28 17:39:00 2005

On Mon, 2005-02-28 at 22:26, Rob Finch wrote:
>The key to this is that four-to-one muxes can be implemented for the
> same cost as two-to-one muxes in an FPGA.
No, the key is that four input functions have the same size as three
input functions. A four-to-one mux is a six input function and requires
in general a lot more logic in a typical FPGA than a two-to-one mux. But
in your case some of the six inputs are identical so you can get along
with one LUT.

> Actually, it doesn't really require any more logic / area than would
> be required for two's complement arithmetic.

> Note the agtb comparison does use up resources that a normal adder
> wouldn't. However this comparison is used elsewhere in the design, so
> I could feed it in as another signal.

So in fact the sign magnitude adder is twice as large as a twos
complement adder but you can share half of these ressources with another
part of your design and therefore the incremental cost is similar to a
twos complement adder.
That is something different than your original claim of both adders
requiring the same resources.

Kolja Sulimma



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: arithmetic - Eric Smith - Feb 28 18:02:00 2005

Rob wrote:
> The key to this is that four-to-one muxes can be implemented for the
> same cost as two-to-one muxes in an FPGA.

Huh? A 2:1 mux only needs a single LUT. A 4:1 needs two LUTs and a
dedicated mux (e.g., the F4 mux), or three LUTs. Or am I missing
something?

Eric



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )