«

On Mon, 14 Jan 2008 23:02:41 -0500,
KJ wrote:

>That being the case, all that is needed then is to strip off the lower bits
>of the result as shown below
>
> RetVal.Real := (a.real * b.real - a.imag * b.imag)(a'range);
> RetVal.Imag := (a.real * b.imag + b.real * a.imag)(a'range);

Urrrm, I don't think you can do that.

You can only subscript an object (variable or signal),
not an expression. You'll need a temporary variable,
or perhaps the resize() function if you can live with
the risk of MSBs getting lost by resize's truncation.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley wrote:

> ...All this stuff can go into a package. If your synth
> tool can cope with numeric_std and records, it can cope
> with this. Yes, I know simulation will be a little slow
> because of all the packing and unpacking of bits into
> the complex data type, but I reckon that's a small price
> to pay for the convenience and regularity of this sort
> of thing:

I reckon you are correct.


> ...
> I have most of this done already; would people find it
> useful if I were to work it up in detail?

It would be an excellent (and rare) example
of the details of packaging a useful type.

(Oh, and would I get some of the credit for the assignments?)

Oh yes. Automatic A on the midterm

-- Mike Treseler

On Jan 18, 12:39*pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Mon, 14 Jan 2008 23:02:41 -0500,
>
> KJ wrote:
> >That being the case, all that is needed then is to strip off the lower bits
> >of the result as shown below
>
> > * * RetVal.Real := (a.real * b.real - a.imag * b.imag)(a'range);
> > * * RetVal.Imag := (a.real * b.imag + b.real * a.imag)(a'range);
>
> Urrrm, I don't think you can do that.
>
Well you also snipped out the wrong portion of my reply where I had my
correction...but you're correct even the correction was flawed, you do
need the resize function...good catch...So updating it yet again

RetVal.Real := resize(a.real * b.real - a.imag * b.imag,
a.real'length);
RetVal.Imag := resize(a.real * b.imag + b.real * a.imag,
a.imag'length);

> or perhaps the resize() function if you can live with
> the risk of MSBs getting lost by resize's truncation.

When choosing the number of bits of precision, one would choose
something large enough so that the result of all mathematical
operations that one is contemplating using will fit into that range as
well so there would be no truncation problems. That's no different
than when using 'integer' type. Proper sizing and numerical
representation though is something that needs to be done before any
coding.

Kevin Jennings

On Jan 18, 11:45*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

<snip of Jonathon's nice work>

> I have most of this done already; would people find it
> useful if I were to work it up in detail? *

Demo of good techniques are always nice to see.

> (Oh, and
> would I get some of the credit for the assignments?)

I'll give you a star....then again, you turned in the assignment 4
days late, might have to dock you for that.

Kevin Jennings

"Jonathan Bromley" <> wrote in message
news:...
> On Mon, 14 Jan 2008 21:20:29 +0100, Nicolas Matringe wrote:
>
> Yes, I know simulation will be a little slow
> because of all the packing and unpacking of bits into
> the complex data type, but I reckon that's a small price
> to pay for the convenience and regularity of this sort
> of thing:

Yet another alternative is to represent the complex as a single array of
std_logic with one half dedicated to 'real', the other half to 'imaginary'.
Now the 'Re' and 'Im' functions are simple one liners that strip out the
appropriate range of bits. Both alternatives provide the same end user
function of producing a complex type that can be of any size that does not
need to be determined a priori.

When debugging, both representations present a challenge for the user to
assemble the bits into a complex number but the single vector approach would
have a bit of an advantage if the number of bits happens to be a multiple of
4 since the number could be displayed in hex in a wave/variables window and
more easily split into the appropriate 'real' and 'imaginary' components of
the complex number.

Since the single vector representation concatenates two equally sized
elements, what the user specifies for a 'width' is the total number of bits
in the complex type (i.e. variable x: complex(15 downto 0) would be used to
get 8 bit precision on the real and imaginary parts).

Both should synthesize down to the same thing (but I haven't actually tested
this).

The single vector representation might also be a good candidate for a
protected type so that the user is completely insulated from details of the
internal representation...but I haven't tried synthesis tools on protected
types yet.

Putting your code into a loop for 2,000,000 iterations vsimk took 58
seconds. Using the single vector representation the same number of loops
took 19 seconds for a 3x sim time advantage.

Kevin Jennings

On Sat, 19 Jan 2008 13:57:06 -0500, "KJ" wrote:

>> Yes, I know simulation will be a little slow
>> because of all the packing and unpacking of bits into
>> the complex data type

>Yet another alternative is to represent the complex as a single array of
>std_logic with one half dedicated to 'real', the other half to 'imaginary'.
>Now the 'Re' and 'Im' functions are simple one liners that strip out the
>appropriate range of bits. Both alternatives provide the same end user
>function of producing a complex type that can be of any size that does not
>need to be determined a priori.

Agreed.

>When debugging, both representations present a challenge for the user to
>assemble the bits into a complex number but the single vector approach would
>have a bit of an advantage

You're right. I hadn't really thought about that hard enough.
I was intending to provide a bunch of "to-string" conversions
(after the manner of std_logic_textio) and also some
non-synthesisable conversions to/from math_complex, to
make debugging and testbench reporting more convenient.

>Since the single vector representation concatenates two equally sized
>elements, what the user specifies for a 'width' is the total number of bits
>in the complex type (i.e. variable x: complex(15 downto 0) would be used to
>get 8 bit precision on the real and imaginary parts).

Yes. I must admit that I see that as a significant drawback,
but obviously it's fairly easy to deal with.

>Both should synthesize down to the same thing
>(but I haven't actually tested this).

I'd be amazed if it wasn't the case. My experience on my
fixed-point package (superseded by the IEEE one) was that
you can do quite complicated things with constants,
subscript calculations and so on, and synthesis will
simply do The Right Thing.

>The single vector representation might also be a good candidate for a
>protected type so that the user is completely insulated from details of the
>internal representation

I guess that would be true for either form...

> ...but I haven't tried synthesis tools on protected
>types yet.

I don't think protected types are, or were intended
to be, synthesisable.

>Putting your code into a loop for 2,000,000 iterations vsimk took 58
>seconds. Using the single vector representation the same number of loops
>took 19 seconds for a 3x sim time advantage.

Interesting, thanks for the experiment. I'm actually quite surprised
that the difference is so small; I'd have expected your representation
to be dramatically faster. I suspect the cost of the unsigned."+"
and unsigned."*" operations is swamping the effect of the
extract/compose functions; if you were to stub-out the complex
multiply with, for example, something that simply concatenated
the two operands:

return to_complex(Re(L) & Re(R), Im(L) & Im(R));

then you might more clearly see the performance hit from my
bit-pairs representation.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

"Jonathan Bromley" <> wrote in message
news:...
> On Sat, 19 Jan 2008 13:57:06 -0500, "KJ" wrote:

>>Both should synthesize down to the same thing
>>(but I haven't actually tested this).
>
> I'd be amazed if it wasn't the case. My experience on my
> fixed-point package (superseded by the IEEE one) was that
> you can do quite complicated things with constants,
> subscript calculations and so on, and synthesis will
> simply do The Right Thing.
>

I'd be surprised also if it wasn't...but I've also generated enough service
requests into synthesis tool providers to know that surprises pop up all
over the place...but you're right I wouldn't expect it to be any problem.
Now that synthesis tools can (or mostly) handle 'time' and 'real' for
computing constants the need to leave the synthesizable subset of the VHDL
language and use some other tool to compute a file that you then need to
import in some fashion is going down.

>> ...but I haven't tried synthesis tools on protected
>>types yet.
>
> I don't think protected types are, or were intended
> to be, synthesisable.
>

Yet, these two examples also demonstrate a reasonable reason why maybe they
should.

>>Putting your code into a loop for 2,000,000 iterations vsimk took 58
>>seconds. Using the single vector representation the same number of loops
>>took 19 seconds for a 3x sim time advantage.
>
> Interesting, thanks for the experiment. I'm actually quite surprised
> that the difference is so small; I'd have expected your representation
> to be dramatically faster. I suspect the cost of the unsigned."+"
> and unsigned."*" operations is swamping the effect of the
> extract/compose functions; if you were to stub-out the complex
> multiply with, for example, something that simply concatenated
> the two operands:
>
> return to_complex(Re(L) & Re(R), Im(L) & Im(R));
>
> then you might more clearly see the performance hit from my
> bit-pairs representation.

Not too much different, vector of records using the above mentioned stub for
+ and * is 4x slower than single vector instead of 3x to compute proper
results.
Stubbing out on the vector of records completed in 49 seconds
Stubbing out on the flat single vector completed in 12 seconds.

Since the Achilles heal of the vector of records approach is that more
precision will proportionately increase the number of times through the
inner loops unravelling the real and imaginary parts in order to do the
math, it's worth investigating the simulation time hit.

Doubling the vector widths results in a 6x difference now.
Stubbing out on the vector of records (16 bit instead of 8 bit components)
completed in 79 seconds
Stubbing out on the flat single vector (16 bit instead of 8 bit components)
completed in 13 seconds.

Doubling the vector widths yet again results in a 10x difference now.
Stubbing out on the vector of records (32 bit instead of 16 bit components)
completed in 142 seconds
Stubbing out on the flat single vector (32 bit instead of 16 bit components)
completed in 14 seconds.

Kevin Jennings

"KJ" <> wrote in message
news:MIxkj.4219$ ...
>
> "Jonathan Bromley" <> wrote in message
> news:...
>> On Sat, 19 Jan 2008 13:57:06 -0500, "KJ" wrote:
>
> Doubling the vector widths results in a 6x difference now.
> Stubbing out on the vector of records (16 bit instead of 8 bit components)
> completed in 79 seconds
> Stubbing out on the flat single vector (16 bit instead of 8 bit
> components) completed in 13 seconds.
>
> Doubling the vector widths yet again results in a 10x difference now.
> Stubbing out on the vector of records (32 bit instead of 16 bit
> components) completed in 142 seconds
> Stubbing out on the flat single vector (32 bit instead of 16 bit
> components) completed in 14 seconds.
>

As one last sim time data point to add, using a record with integers for the
real and imaginary parts is 8x faster than the flat single vector...but that
of course restricts you to using a fixed integer range regardless of what
the data requirements are. But if there comes a day when records can be
parameterized then this would likely be the best approach.

Kevin Jennings

On Jan 20, 2:34*pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "KJ" <kkjenni...@sbcglobal.net> wrote in message
>
> news:MIxkj.4219$ ...
>
>
>
>
>
>
>
> > "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
> >news:.. .
> >> On Sat, 19 Jan 2008 13:57:06 -0500, "KJ" wrote:
>
> > Doubling the vector widths results in a 6x difference now.
> > Stubbing out on the vector of records (16 bit instead of 8 bit components)
> > completed in 79 seconds
> > Stubbing out on the flat single vector (16 bit instead of 8 bit
> > components) completed in 13 seconds.
>
> > Doubling the vector widths yet again results in a 10x difference now.
> > Stubbing out on the vector of records (32 bit instead of 16 bit
> > components) completed in 142 seconds
> > Stubbing out on the flat single vector (32 bit instead of 16 bit
> > components) completed in 14 seconds.
>
> As one last sim time data point to add, using a record with integers for the
> real and imaginary parts is 8x faster than the flat single vector...but that
> of course restricts you to using a fixed integer range regardless of what
> the data requirements are. *But if there comes a day when records can be
> parameterized then this would likely be the best approach.
>
> Kevin Jennings- Hide quoted text -
>
> - Show quoted text -

Thank you all for all your comments. It really helped a lot. I wonder
how many yrs of experience it takes to know so much stuff.

On Jan 19, 12:57 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
>
> news:...
>
> > On Mon, 14 Jan 2008 21:20:29 +0100, Nicolas Matringe wrote:
>
> > Yes, I know simulation will be a little slow
> > because of all the packing and unpacking of bits into
> > the complex data type, but I reckon that's a small price
> > to pay for the convenience and regularity of this sort
> > of thing:
>
> Yet another alternative is to represent the complex as a single array of
> std_logic with one half dedicated to 'real', the other half to 'imaginary'.
> Now the 'Re' and 'Im' functions are simple one liners that strip out the
> appropriate range of bits. Both alternatives provide the same end user
> function of producing a complex type that can be of any size that does not
> need to be determined a priori.
>
> When debugging, both representations present a challenge for the user to
> assemble the bits into a complex number but the single vector approach would
> have a bit of an advantage if the number of bits happens to be a multiple of
> 4 since the number could be displayed in hex in a wave/variables window and
> more easily split into the appropriate 'real' and 'imaginary' components of
> the complex number.
>
> Since the single vector representation concatenates two equally sized
> elements, what the user specifies for a 'width' is the total number of bits
> in the complex type (i.e. variable x: complex(15 downto 0) would be used to
> get 8 bit precision on the real and imaginary parts).
>
> Both should synthesize down to the same thing (but I haven't actually tested
> this).
>
> The single vector representation might also be a good candidate for a
> protected type so that the user is completely insulated from details of the
> internal representation...but I haven't tried synthesis tools on protected
> types yet.
>
> Putting your code into a loop for 2,000,000 iterations vsimk took 58
> seconds. Using the single vector representation the same number of loops
> took 19 seconds for a 3x sim time advantage.
>
> Kevin Jennings

Taking that approach, and borrowing a page from the fixed point
package, you could define the single vector such that natural indices
indicated the real portion, and negative indices indicated the
imaginary portion, in case you wanted different widths for real and
imaginary.

Andy