[Xilinx V4SX55]DDR2 SDRAM controller + dual purpose pins

Hey,

I'm using a V4SX55-FF1148 device and as framebuffer i have build a DDR2 controller ... now i'm having 2 of those controllers in the same device and controller 1 is working perfectly but in controller 0 i have 2 pins that always read 1. no matter what. those 2 pins happen to be on a dual purpose pin (D0/D1 from configuration, but i'm using the serial slave configuration).

All the VREF's are connected to the device on +0.9V, all the IDELAYCTRL's are correctly locked since the other pins of the framebuffer on the same bank give no issue and are working fine ... this is way i'm thinking that is might have something to do with the dual purpose pin configuration? i'm using ISE7.1SP4...

Do any of you have seen such a problem/issue?

hopefully someone can give me a hint ... thanks in advance,

kind regards,

tim

Reply to
Tim Verstraete
Loading thread data ...

did you check the 'persist' option for bitgen? if the D0 is retained as config interface it will not come user io

Antti

Reply to
Antti

No i did not use the persist option in bitgen, that was indeed the first thing i checked ...

thanks in advance,

kind regards

tim

P.S. i add the bitgen log file ...

C:/Xilinx7/bin/nt/bitgen.exe -intstyle ise -w -g DebugBitstream:No -g Binary:no -g CRC:Enable -g ConfigRate:4 -g CclkPin:PullUp -g M0Pin:PullUp -g M1Pin:PullUp -g M2Pin:PullUp -g ProgPin:PullUp -g DonePin:PullUp -g InitPin:Pullup -g CsPin:Pullup -g DinPin:Pullup -g BusyPin:Pullup -g RdWrPin:Pullup -g TckPin:PullUp -g TdiPin:PullUp -g TdoPin:PullUp -g TmsPin:PullUp -g UnusedPin:PullDown -g UserID:0xFFFFFFFF -g DCMShutDown:Disable -g DCIUpdateMode:AsRequired -g StartUpClk:CClk -g DONE_cycle:4 -g GTS_cycle:5 -g GWE_cycle:6 -g LCK_cycle:NoWait -g Security:None -g DonePipe:No -g DriveDone:No -g Encrypt:No toplevel_800board.ncd

Summary of Bitgen Options:

+----------------------+----------------------+ | Option Name | Current Setting | +----------------------+----------------------+ | Compress | (Not Specified)* | +----------------------+----------------------+ | Readback | (Not Specified)* | +----------------------+----------------------+ | CRC | Enable** | +----------------------+----------------------+ | DebugBitstream | No** | +----------------------+----------------------+ | ConfigRate | 4** | +----------------------+----------------------+ | StartupClk | Cclk** | +----------------------+----------------------+ | CclkPin | Pullup** | +----------------------+----------------------+ | DonePin | Pullup** | +----------------------+----------------------+ | HswapenPin | Pullup* | +----------------------+----------------------+ | M0Pin | Pullup** | +----------------------+----------------------+ | M1Pin | Pullup** | +----------------------+----------------------+ | M2Pin | Pullup** | +----------------------+----------------------+ | PowerdownPin | Pullup* | +----------------------+----------------------+ | ProgPin | Pullup** | +----------------------+----------------------+ | InitPin | Pullup** | +----------------------+----------------------+ | CsPin | Pullup** | +----------------------+----------------------+ | DinPin | Pullup** | +----------------------+----------------------+ | BusyPin | Pullup** | +----------------------+----------------------+ | RdWrPin | Pullup** | +----------------------+----------------------+ | TckPin | Pullup** | +----------------------+----------------------+ | TdiPin | Pullup** | +----------------------+----------------------+ | TdoPin | Pullup** | +----------------------+----------------------+ | TmsPin | Pullup** | +----------------------+----------------------+ | UnusedPin | Pulldown** | +----------------------+----------------------+ | GWE_cycle | 6** | +----------------------+----------------------+ | GTS_cycle | 5** | +----------------------+----------------------+ | LCK_cycle | NoWait** | +----------------------+----------------------+ | Match_cycle | Auto* | +----------------------+----------------------+ | DONE_cycle | 4** | +----------------------+----------------------+ | Persist | No* | +----------------------+----------------------+ | DriveDone | No** | +----------------------+----------------------+ | DonePipe | No** | +----------------------+----------------------+ | Security | None** | +----------------------+----------------------+ | UserID | 0xFFFFFFFF** | +----------------------+----------------------+ | ActivateGclk | No* | +----------------------+----------------------+ | ActiveReconfig | No* | +----------------------+----------------------+ | PartialMask0 | (Not Specified)* | +----------------------+----------------------+ | PartialMask1 | (Not Specified)* | +----------------------+----------------------+ | PartialMask2 | (Not Specified)* | +----------------------+----------------------+ | PartialGclk | (Not Specified)* | +----------------------+----------------------+ | PartialLeft | (Not Specified)* | +----------------------+----------------------+ | PartialRight | (Not Specified)* | +----------------------+----------------------+ | Encrypt | No** | +----------------------+----------------------+ | Key0 | pick* | +----------------------+----------------------+ | KeyFile | (Not Specified)* | +----------------------+----------------------+ | StartCBC | pick* | +----------------------+----------------------+ | DCIUpdateMode | AsRequired** | +----------------------+----------------------+ | ICAP_Select | Auto* | +----------------------+----------------------+ | IEEE1532 | No* | +----------------------+----------------------+ | Binary | No** | +----------------------+----------------------+
Reply to
Tim Verstraete

If you by chance are using DCI on those particular pins, they won't work properly unless you've set DCIUpdateMode = "Noisy" ( aka "Continuous" or "AsRequired" )

See: Answer Record # 14887: Virtex-II/-II Pro/-4, Configuration - Dual-purpose configuration pins do not function properly when they are set to a DCI standard

Brian

Reply to
Brian Davis

these are the bitgen options i'm using:

C:/Xilinx7/bin/nt/bitgen.exe -intstyle ise -w -g DebugBitstream:No -g Binary:no -g CRC:Enable -g ConfigRate:4 -g CclkPin:PullUp -g M0Pin:PullUp -g M1Pin:PullUp -g M2Pin:PullUp -g ProgPin:PullUp -g DonePin:PullUp -g InitPin:Pullup -g CsPin:Pullup -g DinPin:Pullup -g BusyPin:Pullup -g RdWrPin:Pullup -g TckPin:PullUp -g TdiPin:PullUp -g TdoPin:PullUp -g TmsPin:PullUp -g UnusedPin:PullDown -g UserID:0xFFFFFFFF -g DCMShutDown:Disable -g DCIUpdateMode:AsRequired -g StartUpClk:CClk -g DONE_cycle:4 -g GTS_cycle:5 -g GWE_cycle:6 -g LCK_cycle:NoWait -g Security:None -g DonePipe:No -g DriveDone:No -g Encrypt:No toplevel_800board.ncd

thanks in advance,

kind regards,

Tim

Brian Davis wrote:

Reply to
Tim Verstraete

Sorry, I managed to chop off a line in my first post - double check the detailed bitgen report to make sure BitGen actually honored your DCIUpdateMode setting.

In 6.something, on a V2Pro, BitGen would automagically set the "quiet" mode if DCI usage were detected, overriding the command line flags.

Even if the report looks OK, I'd investigate dual usage pins further, if you're using DCI, given the past problems.

Although Xilinx removed that DCI pin restriction from the V4 Users Guide, as compared to V2/Pro User's Guide, the restriction has re-appeared in the Answer Records for V4.

Brian

Reply to
Brian Davis

thanks i will definetly check it out ... and might try the bitgen of ISE8.1 + ISE7.1 and do some investigation on it ...

thank you for the interesting tip ... i'll let you know what happens ...

thanks,

kind regards,

Tim

Reply to
Tim Verstraete

I removed any DCI and used the -g DCIUpdateMode:AsRequired and still have the same problem ... i also tried using ISE8.1 and ISE7.1 but they both give me the same result ... could it be that i'm using a Stepping ES device ... i might try the Stepping 1 devices?

thanks in advance,

kind regards,

Tim

Reply to
Tim Verstraete

Hello,

I am using ModelSim PE 6.1b for simulation. I have downloaded XAPP134(SDRAM Controller) form xilinx website. All modules are in VHDL.

SDRAM Controller- VHDL

Micron_VHDL

Testbench_VHDL

It seems the core is not behaving properly with the test bench.

The core state machine always stays in idle state.

Initial violations can be ignored but it stays in idle state even if we run for a longer duration.

Kindly update if there are any changes in the core and also do suggest me how to simulate the

Core using modelsim.

We are facing problems both in functional as well as in timing.pls do the needful

Thanks in advance?

Rajendra CG

Reply to
Rajendra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.