-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomasz Motylewski wrote: |>However, it turns out that the IEEE1364-1995 standard was overruled |>by the -2001 standard which changes the rule to the width of a |>multiply being figured the same way the widths of a sum are figured. |>The older behavior makes much more mathematical sense, but engineers |>are not always logical, and practical engineers even less so:-) | | | What? For me it is clear that when I multiply two 8 bit numbers I will get 16 | bit number. | | If the default has changed to only give upper 8 bit of the result, how do I | still force my code to generate 16 significant bits? Should I do:
Upper 8 bits? You wish:-) No, it's worse then that, you get the *lower* 8 bits.
| input [7:0] a;
| input [7:0] b;
|
| {8'b0,a}*{8'b0,b}
|
| to get full a*b ?Yes. Or assign the result to a 16bit variable, i.e.:
~ wire [15:0] foo = a * b;
In this case, the width is *not* self determined, but determined by the destination location, and everything will be expanded out to the desired 16 bits. Really, things only get weird when the multiply is inside a concatenation operator.
| And what do some FPGA vendors mean by "embedded 18 bit multiplier" ?
They mean "embedded in their FPGA fabric."
- -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCOzcdrPt1Sc2b3ikRAqdfAJ9Mk4ogzZl47tPTqGIyvDyYVto4xQCfZxF4 MQvAVElpTrmfTu3dZ2cQafY= =TByK -----END PGP SIGNATURE-----
