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
On May 18, 5:56=A0pm, whygee <y...@yg.yg> wrote: > Andy wrote: > > signal accum : signed(23 downto 0) :=3D (others =3D> '0'); > > signal input =A0 =A0: signed(13 downto 0) :=3D (others =3D> '0'); > > ... > > --inside a clocked process: > > accum <=3D accum + input; > > operand size mismatch spotted... > > > Andy > > yg > > --http://ygdes.com/http://yasep.org >From the numeric_std package: -- Id: A.4 function "+" (L, R: SIGNED) return SIGNED; -- Result subtype: SIGNED(MAX(L'LENGTH, R'LENGTH)-1 downto 0). -- Result: Adds two SIGNED vectors that may be of different lengths. AndyArticle: 147726
Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote: > Hi, > Is there any public information available about the roll-out schedule > of production (non-ES) Spartan 6 devices, and their final price? Digikey now has the XC6SLX150-2FG484C expected for mif of July -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 147727
Hi all, In my Spartan6 board design, I want to use a Xilinx platform flash to configure it. My Spartan6 is a XC6SLX150 (32.2Mbits configuration memory) and the flash is a XCF32P (32Mbits). I' ve several questions : Is the flash big enough or should I have to use decompression option? How to program the flash with a microcontroller, is it possible with serial or parallele interface, with jtag interface? what other solution would you choose for the memory configuration and which can be updated with a microcontroller? Thank youArticle: 147728
Hi, I'm trying to tidy up the "sdram_wb" SDRAM controller IP core -- and my first target is its excessive use of device resources in the cache control logic. Specifically, it's setting up a 32x32 multi-port read/ write RAM which Xst doesn't recognise, and thus gets implemented as 1024 separate flipflops. This is rather annoying, as it's eating up slices that I need for other things (like, say, the LCD controller). Platform is a Xilinx Spartan-3A XC3S700A on an Enterpoint Drigmorn2 development board. Software is Xilinx ISE 12.1 on Ubuntu 10.04 x86_64. I've reduced the logic down so that it "only" needs two write ports and two read ports. My problem now is that Xst refuses to synthesize it; I get this in the error log: Synthesizing Unit <sdram_wb_cacheline_ram>. Related source file is "sdram_wb_cacheline_ram.v". WARNING:Xst:647 - Input <wr0_mask> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. Found 32x32-bit quad-port RAM <Mram_cacheline_data> for signal <cacheline_data>. Summary: inferred 1 RAM(s). Unit <sdram_wb_cacheline_ram> synthesized. [...] Synthesizing (advanced) Unit <sdram_wb_cacheline_ram>. ERROR:Xst - You are apparently trying to describe a RAM with several write ports for signal <Mram_cacheline_data>. This RAM cannot be implemented using distributed resources. What am I doing wrong here? My code is an almost like-for-like copy of Xilinx's examples (from the Xst manual), except that I've set it up for asynchronous reads. Even making the reads synchronous (by converting the assignments into nonblocking writes in the respective always@ blocks) doesn't appease the demon that is Xst... I really can't think of anything else to try... Here's the code I'm using: module sdram_wb_cacheline_ram #( // This is the width of the SDRAM in bits. parameter SDRAM_DAT_BITS = 32, // The number of cacheline words parameter CACHELINE_WORDS = 32) ( input clk_i, // Clock input input [log2(CACHELINE_WORDS)-1:0] wr0_adr, wr1_adr, // Write port 0 and 1 address input [SDRAM_DAT_BITS-1:0] wr0_dat, wr1_dat, // Write port 0 and 1 data input [(SDRAM_DAT_BITS/8)-1:0] wr0_mask, // Mask bits for write port 0 input we0, we1, // Write enable 0 and 1 input [log2(CACHELINE_WORDS)-1:0] rd0_adr, rd1_adr, // Read port 0 and 1 address output [SDRAM_DAT_BITS-1:0] rd0_dat, rd1_dat // Read port 0 and 1 data ); function integer log2; input [31:0] value; for (log2=-1; value>0; log2=log2+1) value = value>>1; endfunction // Cacheline memory array reg [SDRAM_DAT_BITS-1:0] cacheline_data [CACHELINE_WORDS-1:0]; // Dual-in/dual-out RAM with asynchronous read always @(posedge clk_i) begin if (we0) begin // TODO: masking cacheline_data[wr0_adr] <= wr0_dat; end end always @(posedge clk_i) begin if (we1) begin // TODO: masking cacheline_data[wr1_adr] <= wr1_dat; end end assign rd0_dat = cacheline_data[rd0_adr]; assign rd1_dat = cacheline_data[rd1_adr]; endmodule Thanks, -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147729
On May 19, 12:15=A0pm, Philip Pemberton <usene...@philpem.me.uk> wrote: > Hi, > I'm trying to tidy up the "sdram_wb" SDRAM controller IP core -- and my > first target is its excessive use of device resources in the cache > control logic. Specifically, it's setting up a 32x32 multi-port read/ > write RAM which Xst doesn't recognise, and thus gets implemented as 1024 > separate flipflops. This is rather annoying, as it's eating up slices > that I need for other things (like, say, the LCD controller). > > Platform is a Xilinx Spartan-3A XC3S700A on an Enterpoint Drigmorn2 > development board. Software is Xilinx ISE 12.1 on Ubuntu 10.04 x86_64. > > I've reduced the logic down so that it "only" needs two write ports and > two read ports. My problem now is that Xst refuses to synthesize it; I > get this in the error log: > > Synthesizing Unit <sdram_wb_cacheline_ram>. > =A0 =A0 Related source file is "sdram_wb_cacheline_ram.v". > WARNING:Xst:647 - Input <wr0_mask> is never used. This port will be > preserved and left unconnected if it belongs to a top-level block or it > belongs to a sub-block and the hierarchy of this sub-block is preserved. > =A0 =A0 Found 32x32-bit quad-port RAM <Mram_cacheline_data> for signal > <cacheline_data>. > =A0 =A0 Summary: > =A0 =A0 =A0 =A0 inferred =A0 1 RAM(s). > Unit <sdram_wb_cacheline_ram> synthesized. > > [...] > > Synthesizing (advanced) Unit <sdram_wb_cacheline_ram>. > ERROR:Xst - You are apparently trying to describe a RAM with several > write ports for signal <Mram_cacheline_data>. This RAM cannot be > implemented using distributed resources. > > What am I doing wrong here? My code is an almost like-for-like copy of > Xilinx's examples (from the Xst manual), except that I've set it up for > asynchronous reads. Even making the reads synchronous (by converting the > assignments into nonblocking writes in the respective always@ blocks) > doesn't appease the demon that is Xst... > > I really can't think of anything else to try... > > Here's the code I'm using: > > module sdram_wb_cacheline_ram =A0#( > =A0 // This is the width of the SDRAM in bits. > =A0 parameter SDRAM_DAT_BITS =3D 32, > =A0 // The number of cacheline words > =A0 parameter CACHELINE_WORDS =3D 32) > ( > =A0 input =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clk= _i, =A0 =A0 =A0 =A0 =A0 =A0 =A0// Clock input > =A0 input =A0[log2(CACHELINE_WORDS)-1:0] =A0wr0_adr, wr1_adr, =A0 // Writ= e port 0 and 1 address > =A0 input =A0[SDRAM_DAT_BITS-1:0] =A0 =A0 =A0 =A0 wr0_dat, wr1_dat, =A0 /= / Write port 0 and 1 data > =A0 input =A0[(SDRAM_DAT_BITS/8)-1:0] =A0 =A0 wr0_mask, =A0 =A0 =A0 =A0 = =A0 // Mask bits for write port 0 > =A0 input =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 we0= , we1, =A0 =A0 =A0 =A0 =A0 // Write enable 0 and 1 > > =A0 input =A0[log2(CACHELINE_WORDS)-1:0] =A0rd0_adr, rd1_adr, =A0 // Read= port 0 and 1 address > =A0 output [SDRAM_DAT_BITS-1:0] =A0 =A0 =A0 =A0 rd0_dat, rd1_dat =A0 =A0/= / Read port 0 and 1 data > ); > > function integer log2; > =A0 input [31:0] value; > =A0 for (log2=3D-1; value>0; log2=3Dlog2+1) > =A0 =A0 value =3D value>>1; > endfunction > > // Cacheline memory array > reg [SDRAM_DAT_BITS-1:0] cacheline_data [CACHELINE_WORDS-1:0]; > > // Dual-in/dual-out RAM with asynchronous read > always @(posedge clk_i) begin > =A0 if (we0) begin > =A0 =A0 // TODO: masking > =A0 =A0 cacheline_data[wr0_adr] <=3D wr0_dat; > =A0 end > end > > always @(posedge clk_i) begin > =A0 if (we1) begin > =A0 =A0 // TODO: masking > =A0 =A0 cacheline_data[wr1_adr] <=3D wr1_dat; > =A0 end > end > > assign rd0_dat =3D cacheline_data[rd0_adr]; > assign rd1_dat =3D cacheline_data[rd1_adr]; > > endmodule > > Thanks, > -- > Phil. > usene...@philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current yea= r There are two main problems with this. First, the block rams are synchronous. If you do not do synchronous reads, it can not be a block ram. Second, the block rams only have one address per port. You have separate read and write addresses for each port. What you are describing in this code does not match what the block rams are capable of doing. Regards, John McCaskill www.FasterTechnology.comArticle: 147730
I am running a design using Xilinx ISE 10.1 on a 64-bit machine and after the compilation process I see this error in the ISIM window: Block Memory Generator data initialization complete. Signal SIGSEGV received ERROR: In process BLK_MEM_GEN_V2_8.I948.10 Signal SIGSEGV received This happens only on a 64-bit machine. Any reasons or suggestions ??Article: 147731
On May 19, 8:17=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > 2mm pitch is a good size/strength/standard compromise, but I'd not > > stop at 2x3/2mm; such a standard, should > > have more than one size, the others being super-sets. > > So the minimum common subset, is 2x3, then you add another 2x3 for > > example, to allow more test signals. > > With FT2232 and FT2232H becoming standard, there are a lot of unused > > (but paid for) signals sitting right next to the JTAG ones. > > I'm really just talking about manufacturers JTAG/programming headers. > > There are too many other proprietary combinations to 'standardise'. > Of course, but to become a standard, it needs to be widely useful, and if everyone expands it in different directions, then it is less useful. So, that's why you need to define not only the 'PGM only' sub-set, but also the suggested supersets too. Here's a real example we struck: A 10 pin JTAG header than covers JTAG pgm, but not JTAG fuse override. We found that with just one pin-change, the header could easily do BOTH tasks, and here, a vendor define of both functions, would have been smarter. (and it would have helped their sales too) -jgArticle: 147732
On Wed, 19 May 2010 12:17:40 -0700 (PDT), Vivek Menon <vivek.menon79@gmail.com> wrote: >I am running a design using Xilinx ISE 10.1 on a 64-bit machine and >after the compilation process I see this error in the ISIM window: > >Block Memory Generator data initialization complete. >Signal SIGSEGV received >ERROR: In process BLK_MEM_GEN_V2_8.I948.10 >Signal SIGSEGV received > >This happens only on a 64-bit machine. > >Any reasons or suggestions ?? ISIM in ISE10 has many ways to crash with a SIGSEGV. Unfortunately the only way to find the problem is to remove one block at a time from your design until it stops crashing, then put that block back in and comment out bits of it until you find the cause. Any constructs that are even slightly unusual in your code, are possible candidates for the crash. Once you find it, it is usually easy to work around the problem. Returning access types from functions (workaround: pass them as OUTparameters from a procedure), type conversions in port maps (workaround: use intermediate signals), and connecting INOUT ports from VHDL to a Verilog component are just a few of the causes I have seen. A lot of them have been fixed in ISE 11, so the easiest option might be to upgrade to ISE11 or 12. - BrianArticle: 147733
On May 19, 8:17=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 19 May 2010 12:17:40 -0700 (PDT), Vivek Menon > > <vivek.meno...@gmail.com> wrote: > >I am running a design using Xilinx ISE 10.1 on a 64-bit machine and > >after the compilation process I see this error in the ISIM window: > > >Block Memory Generator data initialization complete. > >Signal SIGSEGV received > >ERROR: In process BLK_MEM_GEN_V2_8.I948.10 > >Signal SIGSEGV received > > >This happens only on a 64-bit machine. > > >Any reasons or suggestions ?? > > ISIM in ISE10 has many ways to crash with a SIGSEGV. > Unfortunately the only way to find the problem is to remove one block at > a time from your design until it stops crashing, then put that block > back in and comment out bits of it until you find the cause. > > Any constructs that are even slightly unusual in your code, are possible > candidates for the crash. Once you find it, it is usually easy to work > around the problem. > > Returning access types from functions (workaround: pass them as > OUTparameters from a procedure), type conversions in port maps > (workaround: use intermediate signals), and connecting INOUT ports from > VHDL to a Verilog component are just a few of the causes I have seen. > > A lot of them have been fixed in ISE 11, so the easiest option might be > to upgrade to ISE11 or 12. > > - Brian Will try compiling modules separately and debug Upgrading to 11 or 12 is not an option. I tried going through the answer records on xilinx for Block Memory Generator v2.8 and could not find any solutions. I don't understand how the BLK_MEM_GEN v2.8 can fail for the 64 bit machine? Something to do with the global values?Article: 147734
In article <ecfe2acf-1053-4f9e-95c2-66e26acc8be3@j9g2000vbp.googlegroups.com>, HIDDEN <zzzz@gmail.com> wrote: > Hi all, > SUPPRESSED by archive owner as a favor to original author If you want a good start, check out the Elphel camera, which is an Aptina sensor, FPGA, and Linux computer in a small package already engineered for you. http://www3.elphel.com/ Even if you don't want to spend the $650 for their hardware (which is a good deal), everything is open source and documented so you can use the code in your own project. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 147735
Final call for registrations to the 1st ever Camp in India. Register now visit http://www.fpgacentral.com/fpgacamp For registration just RSVP here & for more information visit http://www.fpgacentral.com/fpgacamp . For any queries email us at fpgacamp@fpgacentral.com FPGA Camp is the 1st and only open source FPGA conference, which brings engineers together and discusses FPGA, mainly NextGen FPGA technology, application, methodology, best practices and challenges. Also provide a location to meet other local FPGA designers to share their stories. Agenda (visit http://www.fpgacentral.com/fpgacamp for details) 09:00 Registration & Booths 09:30 Welcome & Introductions 09:45 Today's FPGA Ecosystem - Neeraj Varma, Country Manager, Xilinx Gangatharan Gopal, Country Manager, Altera Rakesh Agarwal, Country Manager, Lattice 10:15 Mastering FPGA Design through Debug - Adrian Hernandez, Senior Manager, Xilinx USA 11:00 Tea break 11:30 Trends and challenges in designing with high speed transceivers based FPGAs, and signal Integrity concerns - John Wei, Altera Hong Kong 12:15 Upgrading to SystemVerilog for FPGA Designs - Srinivasan Venkataramanan, CVC 12:45 Lunch & Booths 02:00 Memories; interfaces and controllers - Sandeep Kulkarni, Lattice 02:45 Panel Discussion State of FPGA technology & its adoption in India 03:30 Tea break 04:00 Customer Presentation - RADAR Signal Processing: Case study - Kaushal Jadia,Head, Signal & Data Processing, LRDE/ DRDO Bhishm Tripathi, LRDE 04:30 Vendor Presentations 05:00 Booths Continues Platinum Sponsor Altera Gold Sponsors Xilinx, Lattice, National Instruments Silver Sponsor ARM, Aldec Registration: FREE! Feel free to bring a friend. Just RSVP here or fill the form at http://www.fpgacentral.com/fpgacamp List of Exhibitors Altera Xilinx Lattice ARM Actel Altium Aldec Agilent Technologies Mechatronics Test Equipment (I) Pvt. Ltd iWave Systems Technologies Pvt. Ltd. Synopsys LeCroy Cadence National Instruments Softjin Dexcel Designs Intemsys Manipal.net For more information visit: http://www.fpgacentral.com/fpgacamp/bangalore-india/fpga-camp-21-may-2010-bangalore-indiaArticle: 147736
Hello! Does someone know when this chips XC6SLX16-2CPG196C will be available on the market? On the www.avnet.com availability is 144 week. It's almost 3 years. What is wrong with that? Have you got any info about that? In the begining of this year I was informed that these chips will be on market, in July this year at the latest. I'll be gratitude for soon answer. Best Regards, Jerzy GburArticle: 147737
"David M. Palmer" <dmpalmer@email.com> writes: > If you want a good start, check out the Elphel camera, which is an > Aptina sensor, FPGA, and Linux computer in a small package already > engineered for you. > http://www3.elphel.com/ That's a great advice for a test platform rather than the Aptina kit if zzzz just want to learn FPGA image processing and don't need the features of the MT9J003 that was mentioned initially. The Elphel use the MT9P031 if memory serves me right. Petter -- .sig removed by request.Article: 147738
On Apr 15, 4:48=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 15, 4:31=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin > > > <pmau...@gmail.com> wrote: > > >On Apr 15, 3:12=A0pm, David Brown <da...@westcontrol.removethisbit.com= > > > >wrote: > > > >> Another famous contest involved a C and Ada comparison. =A0It took t= he Ada > > >> more than twice as long as the C team to write their code, but it to= ok > > >> the C team more than ten times as long to debug their code. > > > >Well, this isn't at all the same then. =A0The Verilog teams got workin= g > > >designs, and the VHDL teams didn't. > > > There are two issues to consider. One is the relative times of writing > > the codes vs debugging ie if writing took 5 hours and debugging 10 > > minutes (unlikely) then C still wins. Which brings the second issue: > > it is very likely that the programming contest involved a "larger" > > design to be finished. If I am remembering correctly RTL was =A0an asyn= c > > reset, synchronously loadable up-down counter which is a "smallish" > > project. If programming contest involved something more "involved" it > > still points to the benefit of strong typing and other features of > > Ada/VHDL etc. > > But it's mostly academic and FPGA people who think that VHDL might > have any future at all. =A0See, for example: > > http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl... > > Regards, > Pat Rumors of VHDL's impending death have been around for a while, usually propagated by companies specializing in Verilog tools looking to sell products. This article (from 2003) is little different. Seven years later, and I see that Synopsys is still offering both VHDL and Verilog compilers with their tools. I've seen this claim for nearly the entire time I've been working in the field, and yet I still see VHDL going along quite fine. If anything, the language has been more stable than Verilog, though I will give credit for maintaining backwards compatibility. I just don't see System Verilog being crowned the winner. Perhaps it's just my industry, but I don't see System Verilog much at all. (plenty of Verilog, though) Shoot, if anything; I see tools like Matlab and C-to-RTL tools eventually taking mind-share away from both VHDL and Verilog. One of my previous employers did all of their complex algorithmic work in Matlab, only using VHDL to stitch the final code into a wrapper, or to connect external RAM. While the performance wasn't as great as a purely coded implementation, the design time was reduced dramatically. If that's the extent of your language use, it really matters little which RTL language you use. Lastly, while I often see snarky opinions from ASIC guys about FPGA's high cost per unit, it only takes one bad ASIC spin to pay for a whole lot of Virtex or Stratix parts. The first time you get your new ASIC back, and you find a bug, will be when you start to appreciate the ability reprogram an FPGA in-system, or even remotely. I've even seen ASIC guys have to stick an FPGA on the board to avoid respinning an ASIC. Even if the ASIC vendors abandon VHDL entirely, I'm not going to be all that worried for work. With gate counts and core frequencies increasing all the time, all the while $/gate is plummeting, the performance/size advantage is getting thinner too. I've seen a lot of designs that might have once been done in ASICs being shipped with FPGA's - not all of them low performance of high cost, either. I'm not saying ASICs are going anywhere, as there are definitely applications where the raw speed gain, or low recurring cost, is vital - but for a lot of designs, FPGA's are a realistic option. In short, there is still plenty of room for VHDL, Verilog, Matlab, etc. I think it's a bit premature to pick a "winner"Article: 147739
Hi guys, I could really use some help from an SDRAM / FPGA guru here... I've got an SDRAM controller IP core -- specifically, the sdram_wb core by Stephen Williams, available from the Git repository <git://icarus.com/~steve-icarus/sdram_wb.git>. This core works fine on the Altera DE1, with a 16-bit-wide 64Mbit (1M*16*4bank) PowerChip SDRAM, P/N A2V64S40CTP. The FPGA is a Cyclone II 2C20, and all I had to do to make the core work was add a PLL to shift the SDRAM clock by 2ns. Unfortunately (for me), I hit the limits of what the DE1 could do -- I got the SoC working, but ran out of space for the LCD controller (framebuffer) and audio controller. So I've started playing with the Enterpoint Drigmorn2 board, which uses a Xilinx Spartan3A XC3S700A FPGA, and a 32Mbyte (2M*32*4bank) 32-bit-wide ISSI SDRAM chip, the IS42S32800B. The problem is, while all the other SoC logic (CPU, etc.) seems to work fine, the SDRAM interface just plain won't work. The WISHBONE interface works great (as in, I can R/W the cache, which stores 32 words, split into 4 blocks), but if I do a write/readback that requires a RAM access, the readback returns garbage: ----8<---- SDRAM controller configuration: Status register: 0x00000833 CAS latency = 3 Column address bits = 9 Enabled and ready Refresh Timer: 390 clock cycles CONFIG1: 0x00001010 Trp_clk = 0 Trfc_clk = 1 Trcd_clk = 0 Tras_clk = 1 Cmd> w Write to memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0x55AABBCC Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0x55AABBCC Cmd> w Write to memory Enter address (0x40000000 is added automatically): 0x00000040 Value: 0xBBCC55AA Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000040 Value: 0xBBCC55AA Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0x55AABBCC Cmd> w Write to memory Enter address (0x40000000 is added automatically): 0x00000080 Value: 0x12345678 Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0x7AEDB9CC Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000080 Value: 0x7AFFBDFE ----8<---- Interestingly, as long as I only write to data in the address range [0x00..0x80], the RAM works fine. As soon as I write to address 0x80, all bets are off. The data is not the same each time, but it does remain static: ----8<---- Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0xBD2015AA Cmd> w Write to memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0x12345678 Cmd> w Write to memory Enter address (0x40000000 is added automatically): 0x00000080 Value: 0x89ABCDEF Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0xBD301068 Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0xBD301068 Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000080 Value: 0x8830BDFF Cmd> q Read from memory Enter address (0x40000000 is added automatically): 0x00000000 Value: 0xBD301068 ----8<---- Ordinarily I'd start by checking for timing issues by soldering wires to the pins on the RAM IC, then hooking up the logic analyser. This isn't an option in this case, because the chip is a BGA -- I physically can't get to the pins/pads/balls/whatever. I'd rather not remove the chip because I don't have much experience with BGA rework and I'd probably ruin the (rather expensive) development board. I have tried routing the clocks and SDRAM data lines onto the LHS and RHS header pins, then captured the data with my logic analyser -- this shows that the timing is fine, and also shows that the data being returned is not the same as that written to the SDRAM. I can do a few screen captures and put these online if it helps, although I'll openly admit that timing on the headers =/= timing at the SDRAM (for a start, they're going to be going through different I/O buffers). I've also checked the refresh timing -- it's about 15.6 microseconds (with a 25MHz input clock). I've tried reducing the refresh-timer value to ~12us but this has no effect on the failure symptoms. This is how I have the clocking set up: // Core clock DCM dcm_core_clock DCM_CoreClockGen ( .CLKIN_IN (CLOCK), .RST_IN (DCM_RESET), .CLKFX_OUT (MCLK), .CLKIN_IBUFG_OUT (CLOCK_B), .CLK0_OUT (), .LOCKED_OUT (MCLK_LOCKED) ); // SDRAM clock DCM -- skews the master clock for the SDRAM dcm_sdram DCM_SDRAMClockGen ( .CLKIN_IN (MCLK), // Hold SDRAM DCM in reset until master DCM has locked .RST_IN (DCM_RESET || !MCLK_LOCKED), .CLK0_OUT (), .CLK90_OUT (), .CLK180_OUT (), .CLK270_OUT (SDRAM_CLK), .LOCKED_OUT (SDRAM_CLK_LOCKED) ); CLOCK is a 25MHz clock input from a crystal oscillator. The Core Clock DCM is a throwback to an earlier design which ran at 50MHz, but is currently set up as a "1:1" multiplier (if you can call it that). The SDRAM DCM is set up to mirror the input clock on the output, with different phase shifts. At the moment I'm using the 270deg output, but I've also tried the 0deg and 90deg outputs with no success. SDRAM_CLK is the output pin for the SDRAM clock. Can anyone offer any suggestions for other things I could try (or check)? I'm happy to re-synth the logic or provide logic analyser traces, HDL source, etc. to help out -- but bear in mind I'm limited to 40 logic analyser 'bits' at a time (the Drigmorn2 only has 40 user I/Os). Thanks, -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147740
Hi, Check system memory map. Maybe somthing is covered with something else. Adam > Hi guys, > I could really use some help from an SDRAM / FPGA guru here... > > I've got an SDRAM controller IP core -- specifically, the sdram_wb core > by Stephen Williams, available from the Git repository > <git://icarus.com/~steve-icarus/sdram_wb.git>. This core works fine on > the Altera DE1, with a 16-bit-wide 64Mbit (1M*16*4bank) PowerChip SDRAM, > P/N A2V64S40CTP. The FPGA is a Cyclone II 2C20, and all I had to do to > make the core work was add a PLL to shift the SDRAM clock by 2ns. > > Unfortunately (for me), I hit the limits of what the DE1 could do -- I > got the SoC working, but ran out of space for the LCD controller > (framebuffer) and audio controller. So I've started playing with the > Enterpoint Drigmorn2 board, which uses a Xilinx Spartan3A XC3S700A FPGA, > and a 32Mbyte (2M*32*4bank) 32-bit-wide ISSI SDRAM chip, the IS42S32800B. > > The problem is, while all the other SoC logic (CPU, etc.) seems to work > fine, the SDRAM interface just plain won't work. The WISHBONE interface > works great (as in, I can R/W the cache, which stores 32 words, split > into 4 blocks), but if I do a write/readback that requires a RAM access, > the readback returns garbage: > > ----8<---- > > SDRAM controller configuration: > Status register: 0x00000833 > CAS latency = 3 > Column address bits = 9 > Enabled and ready > Refresh Timer: 390 clock cycles > CONFIG1: 0x00001010 > Trp_clk = 0 > Trfc_clk = 1 > Trcd_clk = 0 > Tras_clk = 1 > Cmd> w > Write to memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0x55AABBCC > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0x55AABBCC > Cmd> w > Write to memory > Enter address (0x40000000 is added automatically): 0x00000040 > Value: 0xBBCC55AA > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000040 > Value: 0xBBCC55AA > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0x55AABBCC > > Cmd> w > Write to memory > Enter address (0x40000000 is added automatically): 0x00000080 > Value: 0x12345678 > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0x7AEDB9CC > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000080 > Value: 0x7AFFBDFE > > ----8<---- > > Interestingly, as long as I only write to data in the address range > [0x00..0x80], the RAM works fine. As soon as I write to address 0x80, all > bets are off. The data is not the same each time, but it does remain > static: > > ----8<---- > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0xBD2015AA > Cmd> w > Write to memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0x12345678 > Cmd> w > Write to memory > Enter address (0x40000000 is added automatically): 0x00000080 > Value: 0x89ABCDEF > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0xBD301068 > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0xBD301068 > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000080 > Value: 0x8830BDFF > Cmd> q > Read from memory > Enter address (0x40000000 is added automatically): 0x00000000 > Value: 0xBD301068 > ----8<---- > > Ordinarily I'd start by checking for timing issues by soldering wires to > the pins on the RAM IC, then hooking up the logic analyser. This isn't an > option in this case, because the chip is a BGA -- I physically can't get > to the pins/pads/balls/whatever. I'd rather not remove the chip because I > don't have much experience with BGA rework and I'd probably ruin the > (rather expensive) development board. > > I have tried routing the clocks and SDRAM data lines onto the LHS and RHS > header pins, then captured the data with my logic analyser -- this shows > that the timing is fine, and also shows that the data being returned is > not the same as that written to the SDRAM. I can do a few screen captures > and put these online if it helps, although I'll openly admit that timing > on the headers =/= timing at the SDRAM (for a start, they're going to be > going through different I/O buffers). > > I've also checked the refresh timing -- it's about 15.6 microseconds > (with a 25MHz input clock). I've tried reducing the refresh-timer value > to ~12us but this has no effect on the failure symptoms. > > This is how I have the clocking set up: > // Core clock DCM > dcm_core_clock DCM_CoreClockGen ( > .CLKIN_IN (CLOCK), > .RST_IN (DCM_RESET), > .CLKFX_OUT (MCLK), > .CLKIN_IBUFG_OUT (CLOCK_B), > .CLK0_OUT (), > .LOCKED_OUT (MCLK_LOCKED) > ); > > // SDRAM clock DCM -- skews the master clock for the SDRAM > dcm_sdram DCM_SDRAMClockGen ( > .CLKIN_IN (MCLK), > // Hold SDRAM DCM in reset until master DCM has locked > .RST_IN (DCM_RESET || !MCLK_LOCKED), > .CLK0_OUT (), > .CLK90_OUT (), > .CLK180_OUT (), > .CLK270_OUT (SDRAM_CLK), > .LOCKED_OUT (SDRAM_CLK_LOCKED) > ); > > CLOCK is a 25MHz clock input from a crystal oscillator. The Core Clock > DCM is a throwback to an earlier design which ran at 50MHz, but is > currently set up as a "1:1" multiplier (if you can call it that). > > The SDRAM DCM is set up to mirror the input clock on the output, with > different phase shifts. At the moment I'm using the 270deg output, but > I've also tried the 0deg and 90deg outputs with no success. > > SDRAM_CLK is the output pin for the SDRAM clock. > > Can anyone offer any suggestions for other things I could try (or check)? > I'm happy to re-synth the logic or provide logic analyser traces, HDL > source, etc. to help out -- but bear in mind I'm limited to 40 logic > analyser 'bits' at a time (the Drigmorn2 only has 40 user I/Os). > > Thanks,Article: 147741
On Fri, 21 May 2010 13:40:04 +0200, Górski Adam wrote: > Check system memory map. Maybe somthing is covered with something else. Nope -- replacing it with a Block RAM (the same WISHBONE RAM core I use for the "safe zone" boot RAM at 0x30000000) makes the RAM test work ("RAM OK, 8KiB detected"). That would seem to suggest that the problem is either: - in the SDRAM controller logic - in the SDRAM clock drive logic / IOBs - on the PCB itself :-/ -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147742
I got this device XC4VLX80 but the speed grade and temperature grade aren't marked on a separate black row near the bottom. how do I know its speed and temperature grade? Thanks for your time! Jasmile --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147743
Hello, i have a strange problem with my FIFO created with Xilinx CoreGenerator for a Spartan 3a. I have a FIFO with a read and write clock separately. The simulation of the design, including the FIFO signals are at this address: http://eech.org/fifoProblem.jpg After a wr_en and a Din and a wr_clk the empty signal stays at '1'! I need a correct empty signal to be able to read from the FIFO. I would be very glad, if someone could help me to solve this problem. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147744
Philip Pemberton pisze: > On Fri, 21 May 2010 13:40:04 +0200, Górski Adam wrote: >> Check system memory map. Maybe somthing is covered with something else. > > Nope -- replacing it with a Block RAM (the same WISHBONE RAM core I use > for the "safe zone" boot RAM at 0x30000000) makes the RAM test work ("RAM > OK, 8KiB detected"). That would seem to suggest that the problem is > either: > - in the SDRAM controller logic > - in the SDRAM clock drive logic / IOBs > - on the PCB itself > > :-/ > Check timings on both boards in result log file and then make proper constraints. Best regards Adam GórskiArticle: 147745
On May 21, 8:22=A0am, "honio" <claudio@n_o_s_p_a_m.eech.org> wrote: > Hello, > > i have a strange problem with my FIFO created with Xilinx CoreGenerator f= or > a Spartan 3a. > > I have a FIFO with a read and write clock separately. > The simulation of the design, including the FIFO signals are at > this address: > > http://eech.org/fifoProblem.jpg > > After a wr_en and a Din and a wr_clk the empty signal stays at '1'! > I need a correct empty signal to be able to read from the FIFO. > > I would be very glad, if someone could help me to solve this problem. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com The empty signal is a read side signal and is synchronous to the read clock. Your simulation does not show any activity on read clock in that time frame, so I would not expect any change on empty. Take a look at a longer time frame that has a few read clocks to see what is happening. Regards, John McCaskill www.FasterTechnology.comArticle: 147746
On Fri, 2010-05-21 at 08:22 -0500, honio wrote: > Hello, > > i have a strange problem with my FIFO created with Xilinx CoreGenerator for > a Spartan 3a. > > I have a FIFO with a read and write clock separately. > The simulation of the design, including the FIFO signals are at > this address: > > http://eech.org/fifoProblem.jpg > > After a wr_en and a Din and a wr_clk the empty signal stays at '1'! > I need a correct empty signal to be able to read from the FIFO. > > I would be very glad, if someone could help me to solve this problem. > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Do you expect to get any empty status output without a read clock? JanArticle: 147747
Hi, I have a Spartan 3E FPGA starter board of 100K gates. I just want to do some basic image processing such as dead pixel correction(I just use black&white images), there is only 8 bits color output and only a Flash ROM embedded. I want to read RAW format file in which includ the pixel information, after simple processing, display it on VGA monitor. My question are: 1 Would my FPGA board suffice for this purpose? 2 If yes, with out extra RAM, how can I get image file into my FPGA? Your help would be really appreciate!Article: 147748
>Do you expect to get any empty status output without a read clock? > >Jan > Yes i wanted to have the empty flag assigned when i first write to the fifo. The readclock is much slower than the writeclock! But i use the empty signal on with the writeclock rate. Think i have to change fifo to a common clock. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147749
On May 21, 6:22=A0am, "jasmile" <samuelliao@n_o_s_p_a_m.gmail.com> wrote: > I got this device XC4VLX80 > =A0but the speed grade and temperature grade aren't marked on a separate > black row near the bottom. how do I know its speed and temperature grade? > Thanks for your time! > Here's the same answer to your question from the Xilinx Forums All production and ES parts produced by Xilinx would be marked correctly, not having this mark is red flag that something is wrong with your supply chain. Ed McGettigan -- Xilinx Inc.
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