Quick synthesis question

D

David Ashley

Guest
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
Click to expand...
 
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
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top