Prev: Power Management for PCIe
Next: Trouble with Altium Openbus document based UART example using TSK3000A
From: LC on 14 Jun 2010 08:45
Hi,

In a design I'm working on I have a machine that produces
128 bit of data. This data is destined to a 16 bit DAC running
8x faster.

Knowing that I can produce the 128bit up to a 120MHz rate
I wanted to generate the 8x 16bit stream as fast as I can
(and I'm using a 500MHz DAC)

The 128 to 16bit It's all done in a component I called front8x
that selects counts and selects the 16bit slice out of the 128bit data
as below (being the clock output the one used to run the rest of the
circuit).

In practice I found it to run up to 300MHz.

Should I expect that this would be the right up limit I could do it ?
Is there any clever design of this frontend to allow higher speed ?

( note: the phase of the clock out to the DAC is set on another PLL so
I'm surely well by setting the DAC to sample at the middle of the eye
pattern. So no issues here )

I would like very much to read some comments, please.

Thanks.

Luis C.

(device CycloneIII-FBGA fastest grade, all outs using LVDS)

--


LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;

ENTITY front8x IS

PORT ( clkin: IN STD_LOGIC; -- master frontend clock
sync: IN STD_LOGIC; -- Sync frontend
clkout: OUT STD_LOGIC; -- 1/8 main clock out
datain: IN STD_LOGIC_VECTOR (127 downto 0);-- system data bus
dacout: OUT STD_LOGIC_VECTOR (15 downto 0)-- DAC data bus
);

END front8x;


ARCHITECTURE regmux8 OF front8x IS

SIGNAL dacreg: STD_LOGIC_VECTOR ( 15 DOWNTO 0 );
SIGNAL datareg:STD_LOGIC_VECTOR ( 127 DOWNTO 0 );
SIGNAL cntr: INTEGER RANGE 0 TO 7;

BEGIN

dacout <= dacreg;


--------------------------
-- Main 8:1 cycle
-- clockout rise at count=4
-- bigdata is fetch at cont = last = 7

main: PROCESS(clkin,sync)

BEGIN
IF (clkin='1' AND clkin'EVENT)
THEN
IF (sync='0') THEN cntr <= 0;
ELSE cntr <= cntr + 1;
END IF;

case cntr is
when 0 => dacreg <= datareg(127 downto 112);
when 1 => dacreg <= datareg(111 downto 96);
when 2 => dacreg <= datareg(95 downto 80);
when 3 => dacreg <= datareg(79 downto 64);
when 4 => dacreg <= datareg(63 downto 48);
when 5 => dacreg <= datareg(47 downto 32);
when 6 => dacreg <= datareg(31 downto 16);
when others => dacreg <= datareg(15 downto 0);
datareg <= datain;

END CASE;

IF (cntr > 4) THEN clkout <= '1';
ELSE clkout <= '0';
END IF;

END IF;

END PROCESS main;

END regmux8;
From: Nial Stewart on 14 Jun 2010 10:34
> Is there any clever design of this frontend to allow higher speed ?

As you're stepping through the 128 bits to extract the 16 bit output
I would have implemented it as a big shift register and take off the
top/bottom bits.

Then all the tools have to worry about is a single register to register delay
rather than big mux required to 'select' the correct 16 bits.


Nial.


From: Symon on 14 Jun 2010 14:45
On 6/14/2010 1:45 PM, LC wrote:
>
> Should I expect that this would be the right up limit I could do it ?
> Is there any clever design of this frontend to allow higher speed ?
>
Does XAPP265 give you any architectural hints that you can use in your
Altera part?
HTH., Syms.
From: LC on 15 Jun 2010 07:57
Symon wrote:
> On 6/14/2010 1:45 PM, LC wrote:
>>
>> Should I expect that this would be the right up limit I could do it ?
>> Is there any clever design of this frontend to allow higher speed ?
>>
> Does XAPP265 give you any architectural hints that you can use in your
> Altera part?
> HTH., Syms.

Tks, Symon,
Indeed there are some variations induced by this reading that I'll try.
Thanks.

Luis C.
From: LC on 15 Jun 2010 08:06
Nial Stewart wrote:
>
> As you're stepping through the 128 bits to extract the 16 bit output
> I would have implemented it as a big shift register and take off the
> top/bottom bits.
>
> Then all the tools have to worry about is a single register to register delay
> rather than big mux required to 'select' the correct 16 bits.
>
>
> Nial.
>

Nial,

Ok, good idea. Tks, will try.
Not sure what you mean by top/bottom but I presume it is something like
having the long 1 bit 128bit SR with outputs at 0, 16, 32 etc while the
parallel 128bit word has bit reordering such as each shift would produce
the next 16bit word to come out. If I'm missing something let me know.

Thanks.
Luis C.

 |  Next  |  Last
Pages: 1 2
Prev: Power Management for PCIe
Next: Trouble with Altium Openbus document based UART example using TSK3000A