FPGA Central

Hi,

I'm studying opencores' ddr source for insight. I
see it makes use of the unisim fddrrse model,
which is very simple -- 2 D inputs, 1 Q output,
Set/reset/enable inputs, 2 clock inputs. If
either clock input goes low to high, Q output
reflects input settings. Just for reference here
it is, but this isn't really the point.

if ( rising_edge(C0) = true) then
if (R = '1') then
Q <= '0' after 100 ps;
elsif (S = '1' ) then
Q <= '1' after 100 ps;
elsif (CE = '1' ) then
Q <= D0 after 100 ps;
end if;
elsif (rising_edge(C1) = true ) then
if (R = '1') then
Q <= '0' after 100 ps;
elsif (S = '1' ) then
Q <= '1' after 100 ps;
elsif (CE = '1') then
Q <= D1 after 100 ps;
end if;
end if;

The Xilinx fpga's have their IOB's, which have
the DDR output block in hardware. The opencores
DDR module doesn't seem to indicate the direct
connections to the IOB's that would have to be
done internal to the chip -- the behaviour is just
written out logically. For synthesis, it skips over
the model for the fddrrse. But elsewhere in the
vhdl code it adds a layer in between the fddrrse
block and the outside world, basically
-- Tristate-Buffer fuer dqs_q
gen_dqs : for n in 0 to DDR_DQS_WIDTH-1 generate
dqs_q(n) <= 'Z' when dqsz_q(n)='1' else dqs(n);
end generate gen_dqs;

dqs is mapped to the 'q' output of an fddrrse. dqsz_q
is another signal which just indicates when the output
should be Z or not.

dqs_q is part of the DDR controller's interface, and
presumably would end up getting mapped to the IOB
by the synthesizer. Those pins would connect directly
to a DDR device.

Now after this long-winded introduction is the question:

Is this all that's necessary to have a synthesizable
code snippet using the IOB's? I mean, in order for
this to work the synthesizer would have to have a
model of the IOB's and know that the imposed tri-state
behaviour can be done using the infrastructure of the
IOB.

The alternative approach would be to explicitly state
all the connections to the IOB, so no intelligence in the
synthesizer would be required -- but I don't seem to
be able to find those mappings. Also this approach would
seem to be device specific, not just within a vendor but
across devices from the same vendor -- IOB's change.
That means code tweaks for each specific device, which
isn't too appealing.

The fddrrse is a simplified representation of the IOB of
a xilinx part. Maybe it isn't even related to an IOB, but
the fddrrse behaviour can be mapped onto an IOB by the
synthesizer.

Thanks for someone to clear this up.
-Dave

I'm not sure exactly what your question was, but Synplicity
automatically recognizes DDR processes, and when the resources are
available (only on primary IOs in applicable FPGAs), it will
automatically implement the appropriate DDR primitive for the target
architectures. The tri-state IOs work the same way.

If the process does not describe the behavior of a primary IO, then DDR
resources are not available, and it will give you an error.

Andy


David Ashley wrote:
> Hi,
>
> I'm studying opencores' ddr source for insight. I
> see it makes use of the unisim fddrrse model,
> which is very simple -- 2 D inputs, 1 Q output,
> Set/reset/enable inputs, 2 clock inputs. If
> either clock input goes low to high, Q output
> reflects input settings. Just for reference here
> it is, but this isn't really the point.
>
> if ( rising_edge(C0) = true) then
> if (R = '1') then
> Q <= '0' after 100 ps;
> elsif (S = '1' ) then
> Q <= '1' after 100 ps;
> elsif (CE = '1' ) then
> Q <= D0 after 100 ps;
> end if;
> elsif (rising_edge(C1) = true ) then
> if (R = '1') then
> Q <= '0' after 100 ps;
> elsif (S = '1' ) then
> Q <= '1' after 100 ps;
> elsif (CE = '1') then
> Q <= D1 after 100 ps;
> end if;
> end if;
>
> The Xilinx fpga's have their IOB's, which have
> the DDR output block in hardware. The opencores
> DDR module doesn't seem to indicate the direct
> connections to the IOB's that would have to be
> done internal to the chip -- the behaviour is just
> written out logically. For synthesis, it skips over
> the model for the fddrrse. But elsewhere in the
> vhdl code it adds a layer in between the fddrrse
> block and the outside world, basically
> -- Tristate-Buffer fuer dqs_q
> gen_dqs : for n in 0 to DDR_DQS_WIDTH-1 generate
> dqs_q(n) <= 'Z' when dqsz_q(n)='1' else dqs(n);
> end generate gen_dqs;
>
> dqs is mapped to the 'q' output of an fddrrse. dqsz_q
> is another signal which just indicates when the output
> should be Z or not.
>
> dqs_q is part of the DDR controller's interface, and
> presumably would end up getting mapped to the IOB
> by the synthesizer. Those pins would connect directly
> to a DDR device.
>
> Now after this long-winded introduction is the question:
>
> Is this all that's necessary to have a synthesizable
> code snippet using the IOB's? I mean, in order for
> this to work the synthesizer would have to have a
> model of the IOB's and know that the imposed tri-state
> behaviour can be done using the infrastructure of the
> IOB.
>
> The alternative approach would be to explicitly state
> all the connections to the IOB, so no intelligence in the
> synthesizer would be required -- but I don't seem to
> be able to find those mappings. Also this approach would
> seem to be device specific, not just within a vendor but
> across devices from the same vendor -- IOB's change.
> That means code tweaks for each specific device, which
> isn't too appealing.
>
> The fddrrse is a simplified representation of the IOB of
> a xilinx part. Maybe it isn't even related to an IOB, but
> the fddrrse behaviour can be mapped onto an IOB by the
> synthesizer.
>
> Thanks for someone to clear this up.
> -Dave

Andy wrote:
> I'm not sure exactly what your question was, but Synplicity
> automatically recognizes DDR processes, and when the resources are
> available (only on primary IOs in applicable FPGAs), it will
> automatically implement the appropriate DDR primitive for the target
> architectures. The tri-state IOs work the same way.
>
> If the process does not describe the behavior of a primary IO, then DDR
> resources are not available, and it will give you an error.
>
> Andy

Andy,

I think you answered my question, thanks. I'm assuming the xilinx
synthesizer would do the same.

Perhaps both options work:
1) Describe interface signal behaviour, and leave it up to the
synthesizer to map that to the IOB functionality, or
2) Describe behavior of signals that will connect to the IOB,
and instantiate the IOB somehow in the VHDL so that the
synthesizer knows to use an actual IOB (and not just mimic
its behaviour).

The Opencores DDR seems to use option 1. Through a friend
working on an actual product I believe I've got evidence for
option 2.

I just don't know how to use option 2 yet. The issue would come
up when trying to make use of on chip resources like PLLs,
multipliers, global clock buffers, etc. I suppose. Perhaps it's in the
constraints file...

-Dave