On Dec 13, 2011, at 11:26 PM, Serguey Zefirov wrote: > Thank you very much. > > Will code in runningSumMaybes_1 remain synthesable if I add my own > add(l,r) and change code along your lines?
The numeric_bit or numeric_std library is just behavior. The meaning of what you create by synthesis is mapped by convention (synthesizable constructs), and can some times be optimized for either speed or area, although just about everything is just speed these days (8 bit adders aren't too impressive in terms of area). The synthesis tool likely understands l+r where l and r are unsigned vectors (defined either in numeric_bit or numeric_std). It'll map that into the appropriate macro or gate level construct. It may not know how to map a ripple adder or a discrete logic adder efficiently because it doesn't know add() is supposed to be mapped onto fast arithmetic as in the case of an FPGA. If you don't care about speed a ripple adder will do, if you do need a something a little better a procedure that does Carry Look Ahead may be good enough. If you absolutely need speed it may be worth trying to convert the function (and your testbench) to std_logic as I described. It may work - you'd expect someone would have notice std_logic unsigned (vectors) not adding correctly by now. Most synthesis tools will swallow std_logic gracefully. There's also the case that you can have two different expressions for simulation (add(l,r) and synthesis (l + r), and use the original code for synthesis. Whether or not you can get away with it is dependent on how you verify post synthesis. If the synthesis tools can produce gate level model you can verify it against vectors from the RTL model (the one you have that you modified). The proof is hardware (gate level model) matching functional simulation. If you can validate results otherwise (capturing from hardware itself) you wouldn't need a gate level VHDL representation. So the answer is you can probably figure out a way to make your project work. _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
