Multiplication operation

Hi every body , i hope that you can help me , i want to do this operation: s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1 when i check the syntax , i have these errors ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. * can not have such operands in this context.

---------------------------------------------------------------------------------------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity operation is Port ( clk : in STD_LOGIC; c1 : in STD_LOGIC_VECTOR (7 downto 0); c2 : in STD_LOGIC_VECTOR (7 downto 0); c 3: in STD_LOGIC_VECTOR (7 downto 0); s: out STD_LOGIC_VECTOR (7 downto 0);

end operation;

architecture Behavioral of operation is

begin

s
Reply to
VHDL_HELP
Loading thread data ...

----------------------------------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------------------------

Can you tell me how the synthesizer will format your floating point result in s so it maps to silicon?

Use scaled integers. Use the precision available in the hardware multipliers to get a rather precise approximation of s. The digital realm is binary, after all, not decimal.

Please read up on how the hardware multipliers perform and how best to utilize them. It's insanely sad to see someone trying to "program" an FPGA rather than design it.

Reply to
John_H

----------------------------------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------------------------

I had a nice, well considered reply that got lost because my newsreader crashed when I was posting the reply. Attempts to cut-and-paste the crashing program failed.

Please respond to the newsgroup rather than directly in order to keep an open conversation and allow others to learn and to help.

I didn't mean to come across as "angry" or "sad" and you shouldn't be sorry about asking the question. What I wanted you to do is look more closely at how the synthesizer might try to build hardware out of your statement.

Condensing what I lost into a few short comments:

looking at c1*0.2, you can instead use the 18-bit signed multipliers in the Xilinx FPGA (17-bit unsigned) to provide a result that is 2^n too large by using 0.2*2^n instead of 0.2 and dividing the result by 2^n (shifting it by n bits) to get the same approximate result with integer arithmetic.

In Verilog, the 17-bit hex number (from 0.2*2^19) and right shift operator could look like

(c1 * 17'h1999a) >> 19

This intermediate value is a good approximation of c1*0.2 but will not necessarily provide "exact" results depending on your expectations.

You could also make the intermediate values compatible with each other so the addition doesn't lose any precision. Rather than losing 19 bits of remainder to get a 6-bit result from your 8-bit c1 value, you could keep more or all of those bits and add the integers and remainders to get less error overall.

You may also benefit by pipelining your operation where you register the c1*17"h1999a intermediate result and add it with the other multiplies on the following clock, producing a result one clock later than with everything performed in parallel.

Read up on the Xilinx multipliers in your target device to understand their implementation, limits, and capabilities.

There are those who believe the first rule in public speaking is to "know your audience" so you can communicate your thoughts most effectively.

I believe the first rule in RTL design should be to "know your silicon" so you can communicate your intents to the synthesizer most effectively.

Hardware design is great fun but the end result is always silicon.

- John_H

Reply to
John_H

First, to address the question, you're not really doing multiplication but performing division through multiplication with decimals. ISE doesn't do division either way. Like John_H said, scale your numbers up (refer to fixed point numbers) so multiplication is done with integers. When done, just scale the result down by the same amount for the final answer. A hint is to scale the numbers by a power of 2 so you just have to do bit shifts.

Second, I would like to give my two cents on John_H's 1990's attitude. You shouldn't tell someone to read up on vendor specific blocks when it is clear that they are just starting out, doesn't need an optimal implementation, and don't have a firm grasp on the basics. You should give them a very simple and concise explanation at their level and a fix at their level. The synthesizer is more than capable of handling the * symbol, the OP doesn't need to worry about what Xilinx puts on the hood. If Xilinx were smart and had good programmers, which it seems they are trying to work towards, no one would need to know of any of the blocks under the hood. People should be able to "program" the hardware. The synthesis program should be smart enough to use the blocks under the hood to provide a near optimal implementation of the "program". There is a reason why people use high level programming languages not assembly. For everyone's sake, "designing" a system on an FPGA shouldn't be hard.

---Matthew Hicks

Reply to
Matthew Hicks

synthesizer

programmers,

assembly.

hi , thank you for your advices first of all , then my equation to resolv is : y=0.299 * R + 0.587 *G + 0.114 * B for me what i tried to do is:

-------------------------------------------------------------------------------------------------------------------- entity rgb is Port ( clk : in STD_LOGIC; R : in STD_LOGIC_VECTOR (7 downto 0); G : in STD_LOGIC_VECTOR (7 downto 0); B : in STD_LOGIC_VECTOR (7 downto 0); Y : out STD_LOGIC_VECTOR (31 downto 0); Cr : out STD_LOGIC_VECTOR (31 downto 0); Cb : out STD_LOGIC_VECTOR (31 downto 0)); end rgb;

architecture arch_rgb of rgb is signal yreg : STD_LOGIC_VECTOR (31 downto 0); begin process (clk) begin

if clk='1' and clk'event then yreg

Reply to
VHDL_HELP

synthesizer

programmers,

assembly.

this program is with syntax correct but not synthetisable , what i tried to d ois to convert the reals with binary ones

Reply to
VHDL_HELP

Matthew let me argue for peace: It all depends on your roots. If you started out as a logic designer (like I did), then you see the FPGA as a wonderful way to design a production-worthy breadboard of terrific complexity and very good performance. God's gift to the logic designer, good-bye wire-wrap! I think in terms of block diagrams, and use VHDL/Verilog to manage the design process. I would never be in doubt about the choice of binary vs decimal, or fixed vs floating point, because they have such enenormous impact on the design efficiency.

If you start out as a computer programmer, then you design=program the way this thread was started, totally oblivious of hardware constraints and limittions. Let the synthesizer worry about those details! The trouble is that these unworthy details can impact the design by an order of magnitude in size=cost and performance.

You will never beat the urge for economy, performance, and design elegance out of us hardware guys. Maybe one day FPGAs will become so big and cheap and fast that it does not matter anymore. Well, hopefully there will always be Social Security. And St. Peter might show mercy with us former pip-pokers genus schemato-saurus. Peter Alfke

synthesizer

programmers,

assembly.

Reply to
Peter Alfke

So where do us embedded systems half-breeds who have done both rank in this comparison? One could postulate that we get 95% of the efficiency of the purebred HW and purebred programmer (rejecting the urge to try for that last 5% which takes all the time), beating you both to market with a design which is elegant, economical, and meets performance requirements since we see from both sides.

:-P ;-))

~Dave~

Reply to
Dave

You go, Dave! Being in this middle ground - in my opinion - give you exceptional insight into strong designs with better time to completion.

A programmer can become hardware aware and cross over enough to get the performance. A hardware guy can get deep enough into the computing side to increase the algorithmic efficiency of the design. It sounds like you're already squarely placed in this productive center.

Reply to
John_H

Reply to
Peter Alfke

Peter, I totally agree with your points and while writing my post I knew there would be a huge difference in perspective because of one, the generation(s) gap, as I am still in graduate school, and two, the background, as I have a C.S. degree. However, my comments were more for beginners who shouldn't be overloaded in the infinite amounts of complexity possible with FPGAs (for an example just read one of Austin's posts). Newbies who are probably working on some trivial project should get the fundamentals first (everything is binary, data flow, ...) and then work towards the actual optimized implementations gradually building in complexity, if constraints deem it necessary. After all, you don't learn to swim in the ocean during a hurricane, you start in the kiddy pool.

Although, I still believe a lot of work needs to be done to synthesis engines so they can better abstract the low-level complexity away from the designer all the while resulting in an optimized implementation. For a quick example, I still cannot believe you don't optimize across files during synthesis. For the time being, I prefer the embedded systems point of view presented in Dave's response.

---Matthew Hicks

Reply to
Matthew Hicks

Reply to
Matthew Hicks

--------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------- >

First, I'm worried you might not have the right VHDL libraries specified for your operation.

I'd suggest you

1) do a sample module with just one multiply, keeping the binary value to 17 bits. If the one multiply - no addition - doesn't work, it's quite possibly a VHDL library issue. I just know that they're touchy - I'm a Verilog guy myself, not VHDL.

2) if the one equation works, define intermediate values for your scaled R, scaled G, and scaled B. Then add those scaled values together to get your result.

3) consider whether VHDL will have a problem assigning a nominally 42-bit result to a 32-bit vector and give you synthesis problems if the results don't match in size.

Please keep in mind that multiplication with real numbers is abstracted in hardware. When it's time to implement the operation, there are issues with precision and error that have to be understood whether you're using an 8-bit ALU or a dual-precision floating point unit. You will have error. The synthesizer doesn't know what to do with the error

- round up? round down? truncate? do something else? - and you must decide what to do to make your math work out. If you're in an 8-bit ALU, you can do operations that are much more precise than 8 bits. You could cascade multiply/shift/add operations to get 8x24 bit multiplies, for instance.

Most of the Xilinx families can multiply 17-bit unsinged values using embedded multipliers. Multiplying an 8-bit color value by a 32-bit constant seems like a bit of overkill. Should the synthesizer perform two multiplies and add the intermediate results together to give you a

40 bit result? Perhaps. Personally, I'm glad the synthesis doesn't try to implement things this way.

I suggested you "know your silicon" not because everyone using the FPGAs should become a down-in-the-transistors hardware guy but because the dedicated resources which will implement this rather resource-intensive operation has specifications on how it operates, just like the arithmetic units in a microprocessor or the single-precision real operation in the C language.

Bottom line: since math in many cases is an abstraction, you have to know how abstract your results will be.

Reply to
John_H

----=AD-----------------------------------------

----=AD------------------

First of all thank you

------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity rgb is Port ( clk : in STD_LOGIC; r : in STD_LOGIC_VECTOR (10 downto 0); g : in STD_LOGIC_VECTOR (10 downto 0); b : in STD_LOGIC_VECTOR (10 downto 0); y : out STD_LOGIC_VECTOR (21 downto 0); cb: out STD_LOGIC_VECTOR (21 downto 0); cr: out STD_LOGIC_VECTOR (21 downto 0)); end rgb;

architecture Behavioral of rgb is signal yr,yg,yb,crr,crb,crg,cbr,cbb,cbg:STD_LOGIC_VECTOR (19 downto

0); signal yy,cr1,cb1:STD_LOGIC_VECTOR (21 downto 0); begin process(clk) begin if clk'event and clk=3D'1' then

-- how to get Y yr

Reply to
VHDL_HELP

Check the end of the preceeding lines. You forgot to end the statements with a semi-colon, like the error message stated.

---Matthew Hicks

Reply to
Matthew Hicks

------------------------------------------------------------------------------------------------

Look at the lines above where the error is flagged. You need to have a semicolon (;) after the crr

Reply to
John_H

ere

----=AD---------------------

Reply to
VHDL_HELP

You do not want synthesis tools to make too many guesses. If you let the synthesis tools guess how you meant to handle floating point numbers, you will end up with unknown precision, unknown rounding, unknown range, etc. Maybe you want to do 18x18 multiplies and only keep the 10 MSBs... or maybe you actually only want the 20 LSBs, the synthesis tools are oblivious to application-specific details and it is the designer's responsibility to fit application-specific stuff into HDL constructs.

As far as optimizing across hierarchy is concerned, Xilinx's ISE and Altera's Quartus DO have options to enable global optimizations. I mostly work with ISE/XST and there are dozens of options to tell how much optimizing you want XST/PAR to do. If you want XST to do global optimizations, you first have to disable "Preserve hierarchy" and most other similarly minded options - but this may make your life miserable if you ever need to debug using ChipScope or post-PAR simulations. Enabling register balancing and moving FFs along with register duplication can also yield major improvements and further contribute to debugging obfuscation. There are dozens of optimization options you can play with if you want/need to.

I would take more robust and efficient synthesis tools over "smarter" ones that try to guess what you want to do any day... XST and other tools already have a hard time correctly processing "dumb" VHDL, the last thing we need is even buggier synthesis tools that try to be smart.

Reply to
Daniel S.

The problem with "the synthesizer should be able to figure it out" comments that keep being thrown around here is that that violates the entire purpose of VHDL. VHDL was intended to be a VERY strongly type'ed language. Which is why (std_logic_vector) * (floating point) is not defined in any standard IEEE library. This is precisely the constraint that makes your synthesis results reliable. Whether the programmers gone hardware designers in the group like it or not, writing VHDL is designing hardware. If you write VHDL with no regard for the hardware that will be built from it, and violate basic design rules, you WILL encounter problems - particularly if you try to get anywhere near the upper speed limit of the part you're designing.

That being said... if you know how you want your multipliers/dividers to be built, I would recommend writing a library to do what you want. Once you define the function "SLV * FLOAT" in a library, you can write statements like that until your heart's content AND be confident in how it will be built because you designed the library.

simple

synthesizer

programmers,

assembly.

Reply to
Paul

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.