From: Ben Marpe on
Hi everybody,

I'm trying to implement a BPSK modulation.
A sin waveform has to be generated at a given frequency (1MHz) with
phase offset (binary PSK i.e. 180°) when transition occures on a data
wire.

Is there any "simple" LogiCORE with BPSK functionality available for my
Xilinx Spartan-3 - Board ?

My attempt would be a LUT in BRAM - but do I have to fill its content
manualy ? The LUT content (e.g. 16bit) could drive a DAC.

On the other hand, If I'm forced to use a external DAC, I might use a
DDS (e.g. AD9834) with all BPSK functionality on chip... ?!?

I'm interested in your ideas and suggestions !

Bye, BEN

From: cs_posting on
Ben Marpe wrote:

> My attempt would be a LUT in BRAM - but do I have to fill its content
> manualy ? The LUT content (e.g. 16bit) could drive a DAC.

There's probably some other way to do it, but I'd just write a quick
program in C or whatver that generates the table in a format compatible
with your HDL or BRAM initializer. Xilinx has a tool which takes a
while to figure out but lets you insert such data into the already
generated bitstream - used it a lot to change the program of a soft
core processor without rebuilding the design.

One thing that can be a bit of a pain is getting the data to be there
in both simulation and in the bitsream - often you have to put it in
twice. If the table isn't very big, encoding it in the HDL might be
simplest?

From: Ray Andraka on
Ben Marpe wrote:

> Hi everybody,
>
> I'm trying to implement a BPSK modulation.
> A sin waveform has to be generated at a given frequency (1MHz) with
> phase offset (binary PSK i.e. 180?) when transition occures on a data
> wire.
>
> Is there any "simple" LogiCORE with BPSK functionality available for my
> Xilinx Spartan-3 - Board ?
>
> My attempt would be a LUT in BRAM - but do I have to fill its content
> manualy ? The LUT content (e.g. 16bit) could drive a DAC.
>
> On the other hand, If I'm forced to use a external DAC, I might use a
> DDS (e.g. AD9834) with all BPSK functionality on chip... ?!?
>
> I'm interested in your ideas and suggestions !
>
> Bye, BEN
>

Since your frequency is only 1 MHz, and assuming you have a clock source
where you can get, say 80 Mhz, you can do the DAC as s sigma-delta DAC
in the FPGA, then all you need outside the FPGA is a resistor and
capacitor. A LUT implemented with block RAM should give you a pretty
clean sine output. Perhaps the easiest way to fill the LUT (assuming
you are using VHDL) is to use excel, matlab, or C to produce one cycle
of sine sampled at your desired pahse resolution as a rounded integer
y= round(2^bits * sin(2*pi*n/resolution)), then cut and paste that data
into a constant integer array in your VHDL, then convert the integer to
the bit vector needed by the BRAM INIT= attribute using a VHDL function.
Alternatively, you could generate ascii binary in your external
application and past that into an array of bit_vectors directly.
From: Ray Andraka on
cs_posting(a)hotmail.com wrote:
> One thing that can be a bit of a pain is getting the data to be there
> in both simulation and in the bitsream - often you have to put it in
> twice. If the table isn't very big, encoding it in the HDL might be
> simplest?
>

Yes, that is a pain. The generics for simulation want a bitvector,
while the attributes for passing to the PAR tools want hex strings.
Rather than enter the tables twice in different formats (and possibly
getting a simulation mismatch), I find it easier to use a VHDL function
to do the conversion of the bit vector to HEX:

function bv2hex (val:bit_vector) return string is
type hex_lut is array (0 to 15) of character;
constant hextable:hex_lut :=
('0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'A', 'B', 'C', 'D', 'E', 'F');
constant str_len:natural:=(val'length+3)/4;
variable temp:integer;
variable ret_string: string(str_len downto 1);
begin
temp:=0;
for j in 0 to val'length-1 loop
if val(j)='1' then
temp:=temp + 2**(j mod 4);
end if;
if (j mod 4)=3 or j=val'length-1 then
ret_string(j/4+1):= hextable(temp);
temp:=0;
end if;
end loop;
return ret_string;
end bv2hex;
From: MikeJ on
Ray, one thought -
I recently had to modify my romgen program (www.fpgaarcade.com) which
produces init strings and generics with a conversion function much as you
suggest.
However the Synplicity tool uses a different attribute style to Mentor's
Precision. I discovered that Synplicity at least will produce the correct
block ram init strings with only the generic set - no synthesis attributes
required.

About time too ....
/Mike

"Ray Andraka" <ray(a)andraka.com> wrote in message
news:gn4Ef.33686$bF.17923(a)dukeread07...
> cs_posting(a)hotmail.com wrote:
>> One thing that can be a bit of a pain is getting the data to be there
>> in both simulation and in the bitsream - often you have to put it in
>> twice. If the table isn't very big, encoding it in the HDL might be
>> simplest?
>>
>
> Yes, that is a pain. The generics for simulation want a bitvector, while
> the attributes for passing to the PAR tools want hex strings. Rather than
> enter the tables twice in different formats (and possibly getting a
> simulation mismatch), I find it easier to use a VHDL function to do the
> conversion of the bit vector to HEX:
>
> function bv2hex (val:bit_vector) return string is
> type hex_lut is array (0 to 15) of character;
> constant hextable:hex_lut :=
> ('0', '1', '2', '3', '4', '5', '6', '7',
> '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'); constant
> str_len:natural:=(val'length+3)/4;
> variable temp:integer;
> variable ret_string: string(str_len downto 1);
> begin temp:=0; for j in 0 to val'length-1 loop if val(j)='1' then
> temp:=temp + 2**(j mod 4);
> end if;
> if (j mod 4)=3 or j=val'length-1 then
> ret_string(j/4+1):= hextable(temp);
> temp:=0;
> end if;
> end loop;
> return ret_string;
> end bv2hex;


 |  Next  |  Last
Pages: 1 2 3
Prev: Xilinx Legal
Next: IP2IP_Addr in IPIF