On 6/12/06, Hamish Marson <[EMAIL PROTECTED]> wrote:
[snip]
>
> The solution is to use a DDR flipflop I/O buffer, and the correct
> one for Lattice is this:
>
> ODDRXC ddr_ff  (.CLK(clock), .DA(for_rising), .DB(for_falling),
> .RST(reset), .Q(to_pin));
>

I understand some of that statement... But not fully... You couldn't
tell me exactly how that works could you? (It's the verilog syntax
that I don't get, not the concept of using the FF).

Especially the slightly different

ODDRXB sck_buf (.DA(1'b0), .DB(CE_) , .LSR (1'b0), .CLK (clock), .Q
(SCK));

that appears in the code... What's the diff between ODDRXB and ODDRXC?
And the .LSR is what?

Sorry. I don't have a verilog reference yet... Amazon (.co.uk) don't
seem to have any that I can find that are particularly relevant...
Except where they're several hundred pounds...


regards
  Hamish.

I think I can help explain.  I'm going to take one step back to help
cover things for other readers.  As I'm sure you've gathered from this
thread already, the DDR buffers are not part of the standard verilog
syntax.  So instead, we instantiate a primitive specific to the fpga
and the synthesizer will model one.   A black box, in other words.
The physical FPGA has some DDR buffer hardware which the snythesizer
can use but will do so only if explicitely requested by the source
code.

I'll explain the syntax then move onto why they were chosen.  The
standard syntax for instantiating any component is
<component name> <unique name> ( <connections> );

The two examples we have are
ODDRXB sck_buf (.DA(1'b0), .DB(CE_) , .LSR (1'b0), .CLK (clock), .Q(SCK));
ODDRXC ddr_ff  (.CLK(clock), .DA(for_rising), .DB(for_falling),
.RST(reset), .Q(to_pin));

For compoents we use ODDRXB and ODDRXC.  the names can be anything but
we chose sck_buf and ddr_ff to help differentiate instantiated
components during simulation and synthesis

As for the connections, the '.name' are ports on the component.  The
text in the paratheses are local wires or registers which we want
connected to the ports.  You can see the same done in the testbench
files for the spi controller and prom.

Where did ODDRXB, ODDRXC, .DA, .LSR, etc come from?  Those are
components and pin names associated with the component.  We got them
from the data sheets provided by lattice.

Lattice ECP2: www.latticesemi.com/dynamic/view_document.cfm?document_id=19040
Lattice ECP/EC and XP:
www.latticesemi.com/dynamic/view_document.cfm?document_id=8520

ODDRXC is located on page 24-25 of ECP2 and ODDRXB is located on page
9 of the XP data sheet.

The only difference between component ports are .LSR and .RST.  These
are functionally equivalent as they are both active high reset signals
so the difference is a matter of naming conventions.

The modules operate the same as far as I can tell.  Synthesis,
however, I would guess requires using ODDRXC on the ECP2 and ODDRXB on
the XP.

Because the Lattice DDR components are FPGA and target specific, the
iverilog simulation tool does not know how to create them.  So intead,
we use a model that we hope is accurate.

I attached a waveform of the following code to show how the model operates.
always @(posedge clock) SCK_reg <= #1 1;
always @(negedge clock) SCK_reg <= #1 CE_;

which should emulate
ODDRXB sck_buf (.DA(1'b1), .DB(CE_) , .LSR (1'b0), .CLK (clock), .Q (SCK));
(Note, I changed .DA to 1'b1 from the earler 1'b0 because that's how I
should have wrttien it in the first place.  It was a typo on my part
and I hope that didn't cause any confusion.)

If you have any more questions feel free to ask.  Thanks for bringing
up this one by the way because I don't know if the rest of us realized
there was a difference in names between FPGA targets.  I saw XB and XC
being tossed around, but couldn't figure out exactly where they were
coming from until I googled the components.

-Ryan

Attachment: ddr_buf_sim.png
Description: PNG image

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to