Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I'm trying to get a Virtex4 PPC405 boot loader to run an ELF file
stored in DRAM.
I have setup the PPC to read binaries from an RS232 and store them in
the DRAM. I've also setup my PC to transfer an ELF file to the PPC.
Now I want to execute the ELF from DRAM, but it isn't working. Using
checksums, I've verified that the file is transferred correctly.
My DRAM starts at 0x00000000, I'm using the XMK function
elf_process_create(0, 0) to try to launch the process. My linker
script for the ELF code I'm trying to launch is attached below. This
was generated by the Xilinx EDK, with the entry point changed to _start
from _boot. Is there anything obvious I'm doing wrong? I'm pretty new
to this stuff, and any advice would be appreciated.
Thanks in advance,
-Till Rosenband
/* Linker script: */
_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x1000;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x1000;
/* Define Memories in the system */
MEMORY
{
DDR_SDRAM_32Mx16_C_MEM0_BASEADDR : ORIGIN = 0x00000000, LENGTH =
0x03FFFFFF
}
/* Specify the default entry point to the program */
/* ENTRY(_boot)
STARTUP(boot.o) */
ENTRY(_start)
/* Define the sections, and where they are mapped in memory */
SECTIONS
{
.text : {
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.init : {
KEEP (*(.init))
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.fini : {
KEEP (*(.fini))
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.rodata : {
__rodata_start = .;
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r.*)
__rodata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.sdata2 : {
__sdata2_start = .;
*(.sdata2)
*(.gnu.linkonce.s2.*)
__sdata2_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.sbss2 : {
__sbss2_start = .;
*(.sbss2)
*(.gnu.linkonce.sb2.*)
__sbss2_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.data : {
__data_start = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d.*)
__data_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.got : {
*(.got)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.got1 : {
*(.got1)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.got2 : {
*(.got2)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.ctors : {
__CTOR_LIST__ = .;
___CTORS_LIST___ = .;
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
__CTOR_END__ = .;
___CTORS_END___ = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.dtors : {
__DTOR_LIST__ = .;
___DTORS_LIST___ = .;
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
__DTOR_END__ = .;
___DTORS_END___ = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.fixup : {
__fixup_start = .;
*(.fixup)
__fixup_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.eh_frame : {
*(.eh_frame)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.jcr : {
*(.jcr)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.gcc_except_table : {
*(.gcc_except_table)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.sdata : {
__sdata_start = .;
*(.sdata)
*(.gnu.linkonce.s.*)
__sdata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.sbss : {
__sbss_start = .;
*(.sbss)
*(.gnu.linkonce.sb.*)
__sbss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.tdata : {
__tdata_start = .;
*(.tdata)
*(.gnu.linkonce.td.*)
__tdata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.tbss : {
__tbss_start = .;
*(.tbss)
*(.gnu.linkonce.tb.*)
__tbss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
.bss : {
__bss_start = .;
*(.bss)
*(.gnu.linkonce.b.*)
*(COMMON)
. = ALIGN(4);
__bss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
/* Generate Stack and Heap Sections */
bss_stack : {
. += _STACK_SIZE;
. = ALIGN(16);
__stack = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
bss_heap : {
. = ALIGN(16);
_heap_start = .;
. += _HEAP_SIZE;
. = ALIGN(16);
_heap_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR
}
Article: 104901
Folks,
[Beginner] I've been trying to decypher a reference design that
contains verilog source and instantiation of modules CLKDLL, IBUFG, and
BUFG. Reading through the source, seven_seg.v, I find the instantiation
of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. It
was provided with development board Xilinx Spartan-3 LC Kit from
Avnet*. I am using ISE 6.3.03i from Xilinx to load the design onto the
board. The problem I am having is that there is no source provided for
these modules, so I am not sure if the ISE fills in their definition
given that project targets the xc3s400-4pq208, or if the user
constraint file (UCF) provides the necessary details, given that the
FPGA chip itself provides the hardware (digital clock manager, i.e.
DCM) that implements the reference.** Since the reference design works,
how are these modules being resolved by the synthesizer (xst) or in the
design flow (e.g. mapper, etc)? If they are coming from a library, how
can I find the documentation explaining these modules? What other
verilog modules are available for us in designs (e.g. where is this
documented)? I know, for example, that this chip has a multiplier.
Thanks for reading,
BEA
*[http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25448%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html]
**[http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf]
//***********************************************************************************
//* File Name: seven_seg.v
//* Version: 1.0
//* Date: February 10, 2004
//* File Hierarchy: Low level module
//* Dependencies: None
//*
//* Designer:
//* Company: Memec
//*
//*
//* Description: This module does the following:
//* 1. Creates a 1-second enable signal with a
logic counter
//* 2. Based on PUSH[2]:
//* Held down : Counts 0-9 on 7-segment
display
//* Released : Displays 4-bit binary DIP
switch value in hex
//* 3. PUSH[1] serves as the system reset
//* 4. LEDs count 0-9
//*
//************************************************************************************
module seven_seg (CLK, PUSH, DIP, DISPLAY, LED);
// Input Declarations
input CLK; //surface-mount 50MHz oscillator
input [2:1] PUSH; //push-button switches
input [3:0] DIP; //DIP[3] is SW3[1] on the board
// Output Declarations
output [6:0] DISPLAY; //7-segment display DD1
output [4:1] LED; //user LEDs
// Input Registers
reg [3:0] DIP_r [3:0]; // 4x4 array to hold registered versions
of DIP
reg [3:0] DIP_d; // debounced DIP
reg [3:0] PUSH1_r; // registered version of PUSH1
reg [3:0] PUSH2_r; // registered version of PUSH2
reg PUSH1_d; // debounced PUSH1
reg PUSH2_d; // debounced PUSH2
// Output Registers
reg [4:1] LED;
reg [6:0] DISPLAY;
// Other Registers
reg [22:0] led_count;
reg [3:0] led_seg_count;
reg reset; // high-asserted reset
// Internal signals
wire led_count_en;
wire clk_i, clk_fb, clk0, clkdv, clk_div16;
integer i;
/* Using CLKDLL to divide the input 50 MHz clock by 16
resulting in a 3.125 MHz internal clock */
IBUFG U1 ( .I(CLK), .O(clk_i));
CLKDLL dll_div_by_16 ( .CLKIN(clk_i), .CLKFB(clk_fb), .RST(1'b0),
.CLK0(clk0), .CLK90(), .CLK180(), .CLK270(),
.CLK2X(), .CLKDV(clkdv), .LOCKED());
BUFG U3 ( .I(clk0), .O(clk_fb));
BUFG U4 ( .I(clkdv), .O(clk_div16));
// Register and debounce push buttons and switches
// If the bouncy signal is high, 4 consecutive lows required to pull it
low
// If the bouncy signal is low, 4 consecutive highs required to pull it
high
always @(posedge clk_div16)
begin
PUSH1_r[0] <= PUSH[1];
PUSH1_r[1] <= PUSH1_r[0];
PUSH1_r[2] <= PUSH1_r[1];
PUSH1_r[3] <= PUSH1_r[2];
if(PUSH1_d)
PUSH1_d <= |PUSH1_r;
else
PUSH1_d <= &PUSH1_r;
reset <= ~PUSH1_d;
PUSH2_r[0] <= PUSH[2];
PUSH2_r[1] <= PUSH2_r[0];
PUSH2_r[2] <= PUSH2_r[1];
PUSH2_r[3] <= PUSH2_r[2];
if(PUSH2_d)
PUSH2_d <= |PUSH2_r;
else
PUSH2_d <= &PUSH2_r;
// Register the 4-bit DIP switch 4 times
DIP_r[0] <= DIP;
DIP_r[1] <= DIP_r[0];
DIP_r[2] <= DIP_r[1];
DIP_r[3] <= DIP_r[2];
// Debounce the DIPs based on the register contents
// For each bit, 0 through 3, switch polarity only when 4 opposite
// polarity is seen for four consecutive clocks.
for (i = 0; i < 4; i = i+1)
begin
if(DIP_d[i])
DIP_d[i] <= DIP_r[0][i] | DIP_r[1][i] | DIP_r[2][i] |
DIP_r[3][i];
else
DIP_d[i] <= DIP_r[0][i] & DIP_r[1][i] & DIP_r[2][i] &
DIP_r[3][i];
end
end
// Segment diagram for the 7-segment LED display (low-enabled).
//
// 0
// -------
// 5| |1
// | |
// ---6---
// 4| |2
// | |
// -------
// 3
// Register outputs
always @(posedge clk_div16)
begin
if(reset) //synchronous reset
begin
DISPLAY <= 7'h7f; //turn off displays during reset
LED <= 4'hf; //turn off LEDs during reset
end
else
begin
// LEDs count binary 0-9 based on led_seg_count
LED <= ~led_seg_count;
// If PUSH2 is pushed (connecting it with GND), encode a
// binary number (0-9) from the counter and displays it
// on the 7-segment LED Display.
// Otherwise, read the DIP switch and output the hex
// value on the 7-segment LED Display
if (!PUSH2_d)
begin
case (led_seg_count)
0: DISPLAY <= ~(7'b0111111);
1: DISPLAY <= ~(7'b0000110);
2: DISPLAY <= ~(7'b1011011);
3: DISPLAY <= ~(7'b1001111);
4: DISPLAY <= ~(7'b1100110);
5: DISPLAY <= ~(7'b1101101);
6: DISPLAY <= ~(7'b1111101);
7: DISPLAY <= ~(7'b0000111);
8: DISPLAY <= ~(7'b1111111);
9: DISPLAY <= ~(7'b1101111);
default: DISPLAY <= 7'b1111111;
endcase
end
else
begin
case (~DIP_d)
0: DISPLAY <= ~(7'b0111111);
1: DISPLAY <= ~(7'b0000110);
2: DISPLAY <= ~(7'b1011011);
3: DISPLAY <= ~(7'b1001111);
4: DISPLAY <= ~(7'b1100110);
5: DISPLAY <= ~(7'b1101101);
6: DISPLAY <= ~(7'b1111101);
7: DISPLAY <= ~(7'b0000111);
8: DISPLAY <= ~(7'b1111111);
9: DISPLAY <= ~(7'b1101111);
4'hA: DISPLAY <= ~(7'b1110111);
4'hb: DISPLAY <= ~(7'b1111100);
4'hC: DISPLAY <= ~(7'b0111001);
4'hd: DISPLAY <= ~(7'b1011110);
4'hE: DISPLAY <= ~(7'b1111001);
4'hF: DISPLAY <= ~(7'b1110001);
default: DISPLAY <= 7'b1111111;
endcase
end // end else (!PUSH2_d)
end // end else (reset)
end // end always block
// The following block generates numbers 0-9 to be displayed on the
7-segment
// display. This 4-bit counter is loaded with the binary value of the
on-board
// DIP switch on reset. Once the reset goes inactive, the count will
begin. The
// counter will hold its last count when the count_hold_n signal goes
active. This
// 4-bit counter will only count 0-9 and is reset to zero when the
counter reaches
// decimal 9.
always @(posedge clk_div16)
begin
if (reset)
led_seg_count <= 4'hf;
else if ((led_seg_count == 4'h9) & (led_count_en == 1'b1))
led_seg_count <= 0;
else if (led_count_en == 1'b1)
led_seg_count <= led_seg_count + 1;
end
// The following counter is used as a prescaler to the above 4-bit
counter.
// The input clock is divided to enable the 4-bit counter once per
second.
always @(posedge clk_div16)
begin
if (reset)
led_count <= 0;
else
if (led_count_en)
led_count <= 0;
else
led_count <= led_count + 1;
end
assign led_count_en = (led_count == 22'd3_125_000); // Create
1-second count
endmodule
#***********************************************************************************
#* Project: Memec Board Spartan-3 400 LC
#*
#* File Name: seven_seg.ucf
#* Version: 1.0
#* Date: February 10, 2004
#*
#* Designer:
#* Company: Memec
#*
#*
#* Description: This module tests the 7-Segment LED display,
DIPs, and
#* push buttons
#*
#************************************************************************************
# Force the FPGA to assert DONE after the DLL locks
INST "dll_div_by_16" STARTUP_WAIT=TRUE;
# Specify a 50 MHz constraint with a Divide-by-16 in the DLL
NET "CLK" TNM_NET = "CLK";
TIMESPEC "TS_CLK" = PERIOD "CLK" 50 MHz HIGH 50 %;
INST "dll_div_by_16" CLKDV_DIVIDE = 16;
# I/O Placement and timing constraints
# Specify set-up and clk-out times
OFFSET = IN 2.4 ns BEFORE "CLK";
OFFSET = OUT 1.9 ns AFTER "CLK";
# Locate DCM & BUFG to ensure they are on the same side as the clk pin
INST "dll_div_by_16" LOC = "DCM_X0Y1" ;
INST "U3" LOC = "BUFGMUX7" ;
INST "U4" LOC = "BUFGMUX6" ;
# I/O input constraints
NET "CLK" LOC = "P184" | IOSTANDARD = LVCMOS33; # SMT clock, JP30
must have jumper at 1-2
# NET "CLK" LOC = "P183"; # clock socket
NET "PUSH<1>" LOC = "P22";
NET "PUSH<2>" LOC = "P24";
NET "PUSH<*>" PULLUP | IOSTANDARD = LVCMOS33;
NET "DIP<3>" LOC = "P26";
NET "DIP<2>" LOC = "P27";
NET "DIP<1>" LOC = "P28";
NET "DIP<0>" LOC = "P29";
NET "DIP<*>" PULLUP | IOSTANDARD = LVCMOS33;
# I/O Output Constraints
NET "DISPLAY<0>" LOC = "P36"; # DISPLAY.1A
NET "DISPLAY<1>" LOC = "P37"; # DISPLAY.1B
NET "DISPLAY<2>" LOC = "P39"; # DISPLAY.1C
NET "DISPLAY<3>" LOC = "P33"; # DISPLAY.1D
NET "DISPLAY<4>" LOC = "P31"; # DISPLAY.1E
NET "DISPLAY<5>" LOC = "P34"; # DISPLAY.1F
NET "DISPLAY<6>" LOC = "P35"; # DISPLAY.1G
NET "DISPLAY<*>" FAST | DRIVE = 24 | IOSTANDARD = LVCMOS33;
NET "LED<1>" LOC = "P19";
NET "LED<2>" LOC = "P18";
NET "LED<3>" LOC = "P21";
NET "LED<4>" LOC = "P20";
NET "LED<*>" FAST | DRIVE = 24 | IOSTANDARD = LVCMOS33;
Article: 104902beagle197@hotmail.com wrote: > Folks, > > [Beginner] I've been trying to decypher a reference design that > contains verilog source and instantiation of modules CLKDLL, IBUFG, and > BUFG. Reading through the source, seven_seg.v, I find the instantiation > of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. It > was provided with development board Xilinx Spartan-3 LC Kit from > Avnet*. I am using ISE 6.3.03i from Xilinx to load the design onto the > board. The problem I am having is that there is no source provided for > these modules, so I am not sure if the ISE fills in their definition > given that project targets the xc3s400-4pq208, or if the user > constraint file (UCF) provides the necessary details, given that the > FPGA chip itself provides the hardware (digital clock manager, i.e. > DCM) that implements the reference.** Since the reference design works, > how are these modules being resolved by the synthesizer (xst) or in the > design flow (e.g. mapper, etc)? If they are coming from a library, how > can I find the documentation explaining these modules? What other > verilog modules are available for us in designs (e.g. where is this > documented)? I know, for example, that this chip has a multiplier. > > Thanks for reading, > BEA > > *[http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25448%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html] > **[http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf] <code snipped> The modules instantiated in the code are Xilinx primitives that correspond to low-level silicon functions not described (for the purposes of synthesis) by Verilog code. Please see the Xilinx Library Guide available in the Xilinx.com online software manuals to see descriptions of those modules.Article: 104903
Super, I found it there, thanks (!) BEA John_H wrote: > beagle197@hotmail.com wrote: > > ... I've been trying to decypher a reference design that > > contains verilog source and instantiation of modules CLKDLL, IBUFG, and > > BUFG. Reading through the source, seven_seg.v, I find the instantiation > > of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. ... > > If they are coming from a library, how > > can I find the documentation explaining these modules? > > The modules instantiated in the code are Xilinx primitives that > correspond to low-level silicon functions not described (for the > purposes of synthesis) by Verilog code. > > Please see the Xilinx Library Guide available in the Xilinx.com online > software manuals to see descriptions of those modules.Article: 104904
I have a valid bitstream and it works fine in the FPGA. BUT ! How do I convert this bitstream into a PROM-file and get the SP305 to work with it ?Article: 104905
In article <1152393183.529370.98410@75g2000cwc.googlegroups.com>, "Peter Alfke" <alfke@sbcglobal.net> writes: >I wish we had never called them "parity bits". They are just extra bits >(above the traditional power of two) that can be used for anything. >Parity is just one of the popular applications, nothing more.. For network applications, they are fantastic as end-of-packet markers. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104906
Jan Hansen schrieb: > I have a valid bitstream and it works fine in the FPGA. > > BUT ! > > How do I convert this bitstream into a PROM-file and get the SP305 to work > with it ? by using Xilinx Impact tool. you may need to read some board docu to setup the jumpers and options properly. Antti http://antti-brain.comArticle: 104907
Hi I have several Spartan3 boards that have a very weird issue, namly when configured with one specific VHDL design using Impact with verify off then after first programming attempt (status fail with CRC check!) the JTAG chain is reported broken before the FPGA and further configuration or even jtag idcode reading is not possible until complete power off the FPGA. When imact option verify is on then however the same bitstream can be used to configure the boards multiply times, the JTAG lockup doesnt happen. It is not related to bad bitstream because the VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or s3-4000) has the same behaviour. The boards in question (2 different PCBs) seem to work with all other design I have tested. To my understanding the JTAG TAP controller should be completly separate function block from the FPGA fabric - so no matter what is loaded as FPGA config should not make the JTAG TAP unscannable. So the issue could be only related to power supply behaviour, some voltage spike at FPGA startup? Any ideas what to test or where to look? Or what to test. I would really like to get to the bottom of the problem and understand how come does LEON3 design make the JTAG Chain to die (this is what is looks like for the moment). The FPGAs on the boards where I see this behaviour are with date codes mentioned in http://direct.xilinx.com/bvdocs/notifications/xcn06018.pdf but I dont think this could be the issue? AnttiArticle: 104908
Xilinx does provide source for their primitives for simulation purposes. Take a look in your Xilinx install directory in the verilog/src/unisims subdirectory. John ProvidenzaArticle: 104909
"Antti" <Antti.Lukats@xilant.com> wrote: >Hi > >I have several Spartan3 boards that have a very weird issue, namly when >configured with one specific VHDL design using Impact with verify off >then after first programming attempt (status fail with CRC check!) the >JTAG chain is reported broken before the FPGA and further configuration >or even jtag idcode reading is not possible until complete power off >the FPGA. When imact option verify is on then however the same >bitstream can be used to configure the boards multiply times, the JTAG >lockup doesnt happen. It is not related to bad bitstream because the >VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or >s3-4000) has the same behaviour. The boards in question (2 different >PCBs) seem to work with all other design I have tested. > >To my understanding the JTAG TAP controller should be completly >separate function block from the FPGA fabric - so no matter what is >loaded as FPGA config should not make the JTAG TAP unscannable. So the >issue could be only related to power supply behaviour, some voltage >spike at FPGA startup? I've had this problem with Spartan2 fpga's. I even cooked a few! So far I could trace the problem, it had to do with power supply current capability and bypassing. Sometimes the fpga will draw a huge amount of current during configuration. If the power supply system (including the bypass capacitors) can't supply this current, you'll have some latch-ups in the fpga. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 104910
Nico Coesel schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote: > > >Hi > > > >I have several Spartan3 boards that have a very weird issue, namly when > >configured with one specific VHDL design using Impact with verify off > >then after first programming attempt (status fail with CRC check!) the > >JTAG chain is reported broken before the FPGA and further configuration > >or even jtag idcode reading is not possible until complete power off > >the FPGA. When imact option verify is on then however the same > >bitstream can be used to configure the boards multiply times, the JTAG > >lockup doesnt happen. It is not related to bad bitstream because the > >VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or > >s3-4000) has the same behaviour. The boards in question (2 different > >PCBs) seem to work with all other design I have tested. > > > >To my understanding the JTAG TAP controller should be completly > >separate function block from the FPGA fabric - so no matter what is > >loaded as FPGA config should not make the JTAG TAP unscannable. So the > >issue could be only related to power supply behaviour, some voltage > >spike at FPGA startup? > > I've had this problem with Spartan2 fpga's. I even cooked a few! So > far I could trace the problem, it had to do with power supply current > capability and bypassing. Sometimes the fpga will draw a huge amount > of current during configuration. If the power supply system (including > the bypass capacitors) can't supply this current, you'll have some > latch-ups in the fpga. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl hi thanks for answer, and yes that is what I think also the problem could be. but I assumed the Spartan 3 has no special requirements of huge currents required to startup. both 1.2 and 2.5V powersupplies are 6A step-downs from LT and look like really designed by the book. Gosh I really hate if I need to troubleshoot them. I still wonder why the latchup never happens when I select "verify on" in impact !? guess I need to setup up DSO trigger on done=1 and monitor all the supplies at the transition time. AnttiArticle: 104911
I'm not that familiar with Xilinx's FPGA's; but I did have an issue with an Altera FPGA that turned out to be power supply related. The problem was that the power-up configuration was unstable, sometimes it would work and other times it wouldn't. But, if I powered up, then initiated a configuration (from an on board push-button), it always worked. This led me to look at the power rails. In my case, I had a power supply that was generating a non-monotonic rise on VCCint. Once I fixed the rise so that it was smooth the problem went away. Can you initiate, or re-initiate, the configuration cycle after you are powerd up and the voltage rails are stable? If so, try it, and see what happens. It may give you another clue. Take care, Rob "Antti" <Antti.Lukats@xilant.com> wrote in message news:1152431443.921543.193450@m79g2000cwm.googlegroups.com... > Hi > > I have several Spartan3 boards that have a very weird issue, namly when > configured with one specific VHDL design using Impact with verify off > then after first programming attempt (status fail with CRC check!) the > JTAG chain is reported broken before the FPGA and further configuration > or even jtag idcode reading is not possible until complete power off > the FPGA. When imact option verify is on then however the same > bitstream can be used to configure the boards multiply times, the JTAG > lockup doesnt happen. It is not related to bad bitstream because the > VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or > s3-4000) has the same behaviour. The boards in question (2 different > PCBs) seem to work with all other design I have tested. > > To my understanding the JTAG TAP controller should be completly > separate function block from the FPGA fabric - so no matter what is > loaded as FPGA config should not make the JTAG TAP unscannable. So the > issue could be only related to power supply behaviour, some voltage > spike at FPGA startup? > > Any ideas what to test or where to look? Or what to test. I would > really like to get to the bottom of the problem and understand how come > does LEON3 design make the JTAG Chain to die (this is what is looks > like for the moment). > > The FPGAs on the boards where I see this behaviour are with date codes > mentioned in > > http://direct.xilinx.com/bvdocs/notifications/xcn06018.pdf > > but I dont think this could be the issue? > > Antti >Article: 104912
Rob schrieb: > I'm not that familiar with Xilinx's FPGA's; but I did have an issue with an > Altera FPGA that turned out to be power supply related. The problem was > that the power-up configuration was unstable, sometimes it would work and > other times it wouldn't. But, if I powered up, then initiated a > configuration (from an on board push-button), it always worked. This led me > to look at the power rails. In my case, I had a power supply that was > generating a non-monotonic rise on VCCint. Once I fixed the rise so that it > was smooth the problem went away. > > Can you initiate, or re-initiate, the configuration cycle after you are > powerd up and the voltage rails are stable? If so, try it, and see what > happens. It may give you another clue. > > Take care, > Rob Hi Rob, 1) I can configure and reconfigure the board with many many different designs and never see an issue at all. 2) when using one specific design/bitstream then I can configure and reconfigure any number of times when Xilinx impact is set to perform configure and verify. Impact even reports programming and verify success !! 3) using the same bitstream and impact with configure, but no verify then first configuration attempts says configure error (CRC error) and after that the JTAG chain is reported as broken before the FPGA. The power supplies are still proper Voltage and stable and the FPGA does not get hot. But it needs to be power cycled for the JTAG TAP to come live again. I understand that power supply is the most likely issue but why doesnt the issue never happen when jtag operation is set to configure_and_verify? and locks up the jtag tap 100% when attempting to configure without verify? I bet this remains "Xilinx mystery" forever. AnttiArticle: 104913
Anti, All devices after Virtex E (Sparta 2E) have no extra current required over that which is specified in the data sheet for minimum power on current. Is it possible that the configuration you are loading requires more power than you have available? I have seen DONE go high, only for the power supply to crash, fold back, and the part starts to reconfigure again. As for the JTAG state machine, it is definitely possible for it to enter a "bad" state from which it may never recover. It is only with Virtex 4, and now Virtex 5, that we have worked carefully on the state machines to harden them from soft errors, which might place them in an unrecoverable state. Irradiation with neutrons can quickly find those hidden bad states! AustinArticle: 104914
Austin Lesea schrieb: > Anti, > > All devices after Virtex E (Sparta 2E) have no extra current required > over that which is specified in the data sheet for minimum power on current. > > Is it possible that the configuration you are loading requires more > power than you have available? > > I have seen DONE go high, only for the power supply to crash, fold back, > and the part starts to reconfigure again. > > As for the JTAG state machine, it is definitely possible for it to enter > a "bad" state from which it may never recover. It is only with Virtex > 4, and now Virtex 5, that we have worked carefully on the state machines > to harden them from soft errors, which might place them in an > unrecoverable state. Irradiation with neutrons can quickly find those > hidden bad states! > > Austin Hi Austin, I also did think there is no extra power surge at configuration on S3. I do not think the design takes more power then available. I was just porting LEON3 design onto some new boards to have more designs for the board test. To my very surprise the LEON3 design never started up correctly. I did make the design smaller by disabling MMU and caches and the problem persisted. The desing uses 13% of S3-4000 and is set to run from 25MHz. All power supplies are rated to 6A. The same board runs succesfully a Microblaze desing with two separate SDRAM controllers, ethernetand TFT display cores at 72MHz, I would bet that design should defenetly burn more dynamic current than the plain vanilla LEON3 design. Ok I cant measure the LEON3 design power as it never comes up live. Wrong I can, I have one Memec board with s3-1500 I can load the design that fails on my board onto memec and measure current and then measure current on my boards with some design that do work. That should tell if the boards that fails do work with the current that the LEON3 design requires. As of JTAG dead states - that fact that Xilinx has only ironed it out for V4 and V5 really surprises me. A JTAG TAP isnt rocket sience. -- I havent been able to test with non JTAG configuration methods yet maybe the all issue is only with impact software - the JTAG chain contains a Atmel AT91SAM7S ARM with JTAGSEL=0 eg the ARM ICE JTAG chain is selected. It is remotly possible that the ARM JTAG is getting messed up somehow. This could even explain why there is difference when configuring with verify on and off. Well it means that I have stumbled into some very nasty Impact bug? I know that the ARM ICE JTAG is not 100% proper JTAG but as long as it.. hmm maybe i solved the issue at this very moment, as the ARM JTAG has a bug that disturbs some JTAG operations when JTAG clock is over system clock and the Atmel ARM powers up with internal 128KHz clock, then it is remotly possible it gets upset somehow. As I did not see problem so far I assumed the ARM BYPASS works at higher speeds also (but all assumptions are wrong). If I think of it, then it sounds like that this must be the problem. Just weird that every other design worked so far and one design doesnt. AnttiArticle: 104915
Is while loop synthesizable if the number of iterations is known If yes then how come for is not synthesizable I heard for is not synthesizable is that trueArticle: 104916
On 2006-07-09, thejay <elec.jay@gmail.com> wrote:
> Is while loop synthesizable if the number of iterations is known
> If yes then how come for is not synthesizable
>
> I heard for is not synthesizable is that true
For constant limits on an integer value it should work:
integer i;
always @(posedge clk)
if (ce && ~rst) begin
for (i = 0; i < depth - 1; i = i + 1)
fifo[i] <= fifo[i+1];
fifo[depth - 1] <= d;
end
--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/
Article: 104917I didn't think that was the problem, but I thought I would throw it out there. Bizarre problem indeed. Please post when you find the answer. "Antti" <Antti.Lukats@xilant.com> wrote in message news:1152471480.276262.151590@35g2000cwc.googlegroups.com... > Rob schrieb: > >> I'm not that familiar with Xilinx's FPGA's; but I did have an issue with >> an >> Altera FPGA that turned out to be power supply related. The problem was >> that the power-up configuration was unstable, sometimes it would work and >> other times it wouldn't. But, if I powered up, then initiated a >> configuration (from an on board push-button), it always worked. This led >> me >> to look at the power rails. In my case, I had a power supply that was >> generating a non-monotonic rise on VCCint. Once I fixed the rise so that >> it >> was smooth the problem went away. >> >> Can you initiate, or re-initiate, the configuration cycle after you are >> powerd up and the voltage rails are stable? If so, try it, and see what >> happens. It may give you another clue. >> >> Take care, >> Rob > > Hi Rob, > > 1) I can configure and reconfigure the board with many many different > designs and never see an issue at all. > > 2) when using one specific design/bitstream then I can configure and > reconfigure any number of times when Xilinx impact is set to perform > configure and verify. Impact even reports programming and verify > success !! > > 3) using the same bitstream and impact with configure, but no verify > then first configuration attempts says configure error (CRC error) and > after that the JTAG chain is reported as broken before the FPGA. The > power supplies are still proper Voltage and stable and the FPGA does > not get hot. But it needs to be power cycled for the JTAG TAP to come > live again. > > I understand that power supply is the most likely issue but why doesnt > the issue never happen when jtag operation is set to > configure_and_verify? and locks up the jtag tap 100% when attempting to > configure without verify? > > I bet this remains "Xilinx mystery" forever. > > Antti >Article: 104918
>AH! We have the first condition for chaotic behaviour, sensitivity to >initial conditions... When the input is near the balance point, the >slightest difference will determine whether the output goes positive or >negative. That is a very significant aspect of the circuit. When I think of chaos, I think of hard to predict systems. The classic example is the earth's weather pattern. We think we can analyze the local details but we can't predict anything long term. In the case of metastability, the system eventually stabilizes at a 1 or 0. That's two possible states rather than zillions. Is it called "chaotic" if I can't predict when it will stabilize? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104919
>The reason for this requirement is the specification claims that the timing >budget does not cover the time for the "reflected wave" to return to the >driving device in time to be properly received by the next clock edge. As >you pointed out, it is hard to imagine this being a big issue at 33 MHz, but >at 133 MHz, I would not dare ignore it. This gets interesting. In the old/slow days, PCI was a multi-drop bus system. If the reflected wave didn't get back to you, it (most likely) didn't get back to the chip/card right next to you either. The timing budged had to cover that case so you got a free ride. Are newer/faster PCI systems limited to point-point links rather than multi-drop busses? Are there requirements on the driving/source (termination) impedance to damp out multi-trip reflections? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104920
(Hal Murray) wrote: > >>AH! We have the first condition for chaotic behaviour, sensitivity to >>initial conditions... When the input is near the balance point, the >>slightest difference will determine whether the output goes positive or >>negative. That is a very significant aspect of the circuit. > >When I think of chaos, I think of hard to predict systems. The classic >example is the earth's weather pattern. We think we can analyze the >local details but we can't predict anything long term. > >In the case of metastability, the system eventually stabilizes at >a 1 or 0. That's two possible states rather than zillions. > >Is it called "chaotic" if I can't predict when it will stabilize? No. Chaotic means that it doesn't stabilize. A flipflop with chaotic metastability, if setup or hold times were not honored, could oscillate without a fixed period until the next clock edge. This doesn't seem useful to me, but it is clearly a possibility. TTL at least came close to this, as one of the metastable failure modes of at least some TTL flipflops was an oscillation until the next clock edge. -- Phil Hays (Xilinx, but speaking for himself)Article: 104921
Hi, all: The FFs can be reset synchronously or asynchronously. And in ASIC design, the FFs with asynchronous reset will be "smaller". But in FPGA design, will the FFs with asynchronous reset perform better than the ones with synchronous reset? Or, is the kind of reset just an "option" for the FFs instantiated?Article: 104922
On 9 Jul 2006 20:35:03 -0700, "Stanley Lee" <lizhongqi@hotmail.com> wrote: >Hi, all: >The FFs can be reset synchronously or asynchronously. And in ASIC >design, the FFs with asynchronous reset will be "smaller". I am not sure why you put it into quotes but this statement is almost definitely false. I've never seen an ASIC library where the async reset flops were not larger in area than non-reset flops from which one usually makes the sync flops. Non-reset flops are also usually faster and the resulting design is faster again because one usually has a path in the logic which resets the flop so the sync reset gets merged with that path.Article: 104923
On Sat, 08 Jul 2006 21:36:22 -0000, gavin@allegro.com (Gavin Scott) wrote: >So I've been on the mailing list for Xilinx's Xcell Journal glossy >magazine for a year or two now, and something I've noticed is that >EVERY issue I've received is trashed to one degree or another. The >covers are torn, the corners crushed or completely folded over, etc. > >After 4-5 issues I'm starting to get suspicious that Xilinx has a >problem with their mailing house rather than that I've just had >really bad luck or the postal service is run by Altera or something. > >Issue 57 showed up in the last couple weeks, and while attempting to >browse through it (something made difficult by several parts of the >cover missing, the lower right corner folded over, and the bottom and >right middle edges smashed in), I notice that on what's left of the >"Letter from the Publisher" page, the post office has applied a large >red stamp mark that reads "Received in damaged condition". This >suggests to me that the problem happened before the magazine reached >the post office. > >So, I thought I would come and ask if this is just me that's gotten >unlucky or whether other people are having similar issues (pun not >intended, well, ok, maybe a little). > >G. I receive my copy on Spain with no damage at all. I would blame your postal service or postal office. Z.Article: 104924
mk =E5=86=99=E9=81=93=EF=BC=9A > On 9 Jul 2006 20:35:03 -0700, "Stanley Lee" <lizhongqi@hotmail.com> > wrote: > > >Hi, all: > >The FFs can be reset synchronously or asynchronously. And in ASIC > >design, the FFs with asynchronous reset will be "smaller". > > I am not sure why you put it into quotes but this statement is almost > definitely false. I've never seen an ASIC library where the async > reset flops were not larger in area than non-reset flops from which > one usually makes the sync flops. Non-reset flops are also usually > faster and the resulting design is faster again because one usually > has a path in the logic which resets the flop so the sync reset gets > merged with that path. Thank you for your answer, and what you say is about ASIC or FPGA? I want to know the performance of the two kind of FFs in FPGA. Thank you once again.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z