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
Given Top_Bot bit, Block Type (say CLB), Row addre, column addr and minor addr, the address of configuration frame is fixed. However, inside this frame, there are 41 words. Is there any document that describe the frame bits details? For example, in V4FX60, CLB of tile offset X57Y127 has Top_B Bit = 0, Block Type = 0, Row Addr = 3, Column Addr = 51, Minor Addr = 19. Slice X90Y254 is in this CLB. How can I find which word in this frame is corresponding to the F LUT of Slice X90Y254? thanksArticle: 143176
Rick, You were right, I can not refute you at this time it is $6.10 per board so it stands no one can do it for $6 a board. Yes, they do a minimum of $50.00. Still that seems good, no that seems great! Cy From matthieu.d.u.m.m.y.michon@gmail.com Thu Sep 24 08:39:55 2009 Path: unlimited.newshosting.com!s02-b86!num01.iad!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!cleanfeed2-a.proxad.net!nnrp6-2.free.fr!not-for-mail Date: Thu, 24 Sep 2009 17:39:55 +0200 From: Matthieu Michon <matthieu.d.u.m.m.y.michon@gmail.com> Newsgroups: comp.arch.fpga Subject: Re: Xilinx XST and counter synthesis problem Message-Id: <20090924173955.0a626032.matthieu.d.u.m.m.y.michon@gmail.com> References: <0cf0b35f-6680-48c2-9b45-21f758b37679@e34g2000vbm.googlegroups.com> <7hsjjqF2udr0gU1@mid.individual.net> <cfbc382f-65b6-4eb5-8077-5514eac8e0a2@r36g2000vbn.googlegroups.com> <8b4f03ad-0c13-4525-a3ee-174b10c219bc@s6g2000vbp.googlegroups.com> <7f37472c-26d3-40b9-9ef9-07d60fb5a9ef@o35g2000vbi.googlegroups.com> <2f4558a6-ad91-406c-871c-d9b90b3b27a3@p23g2000vbl.googlegroups.com> X-Newsreader: Sylpheed 2.7.1 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 30 Organization: Guest of ProXad - France NNTP-Posting-Date: 24 Sep 2009 17:39:54 MEST NNTP-Posting-Host: 213.215.9.6 X-Trace: 1253806794 news-3.free.fr 4968 213.215.9.6:50158 X-Complaints-To: abuse@proxad.net Xref: unlimited.newshosting.com comp.arch.fpga:93821 X-Received-Date: Thu, 24 Sep 2009 15:39:55 UTC (s02-b86) On Thu, 24 Sep 2009 01:28:11 -0700 (PDT) "nic_o_mat@msn.com" <nic_o_mat@msn.com> wrote: > (...) > I always use an asynchronous reset description in my processes but the > actual reset signal is synchronized in another block. > I only posted the offending entity, the design is larer than this > single file. > > I am no beginner and I did simulate my design before synthesizing it. > Simulation runs absolutely fine. > I have made further investigation, the SPI master generates the > correct number of clock cycles but only the 12 first bits are > transmitted, MOSI then goes high. > > Nicolas In the case of a discrepancy in the behavior between simulation and execution, I would check the usuals : - Synthesis and implementation transcript for anything even remotely suspicious (while focusing manly on the logic optimization and timing). - Reset signal synchronization is performed against the _correct_ clock net. - RTL and physical (low-level) FPGA implementation of your design. While you may not have access to the JTAG interface of the FPGA (o/w I guess you'd already have used chipscope to probe the revelant nets), you can always throw a post p/r simulation, just to make sure that the toolchain didn't caught its feet in the rug while implementing your design. Hope this helps. -- Matthieu MichonArticle: 143177
im, Why? ( I am curious) One easy way to find things is to use FPGA_editor to create two identical designs, with different logic equations in the LUT of interest. Use "diff" (or equivalent) to find the difference in the two bitstreams. AustinArticle: 143178
On Sep 24, 5:30=A0pm, nobody <cydrollin...@gmail.com> wrote: > Rick, > > You were right, I can not refute you at this time it is $6.10 per > board so it stands no one can do it for $6 a board. Yes, they do a > minimum of $50.00. Still that seems good, no that seems great! > > Cy min order 50$ no setup fee for 4 layer? and free shipping? this is pretty good if so AnttiArticle: 143179
On Sep 24, 6:53=A0pm, austin <aus...@xilinx.com> wrote: > im, > > Why? ( I am curious) > > One easy way to find things is to use FPGA_editor to create two > identical designs, with different logic equations in the LUT of > interest. =A0Use "diff" (or equivalent) to find the difference in the > two bitstreams. > > Austin hm if that is the easy way, what is the hard way? AnttiArticle: 143180
Hello! > For example, in V4FX60, CLB of tile offset X57Y127 has Top_B Bit = 0, > Block Type = 0, Row Addr = 3, Column Addr = 51, Minor Addr = 19. Slice > X90Y254 is in this CLB. How can I find which word in this frame is > corresponding to the F LUT of Slice X90Y254? I don't think that there is an official document, because this would reveal some technological information about the structure of their devices Xilinx likes to keep secret, BUT, there was a project able to somehow dissassamble the bitstream: http://www.ulogic.org. Maybe it provides the information you have been looking for. Regards, Ulrich LangenbachArticle: 143181
Antti.Lukats@googlemail.com wrote: > hm if that is the easy way, what is the hard way? The hard way would be to use two different VHDL files and compare the bitstreams :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 143182
On Sep 23, 6:11=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > > On Sep 23, 7:56 pm, rickman <gnu...@gmail.com> wrote: > >> I was looking up the shift operator in VHDL since I seldom use it and > >> saw that there is both a shift left logical and a shift left > >> arithmetic. =A0The logic shift left shifts in zeros and the arithmetic > >> shift left shifts in the value of the lsb. > > sla shifts left and copies the right bit. > > Use of sla and sll on std_logic_vector is depreciated since > numeric_standard.shift_left automatically does the > "right thing" with the edge bits for signed or unsigned types. > > Antti.Luk...@googlemail.com wrote: > > how is this related to FPGA? > > VHDL is a popular design entry language for FPGAs. > Up until today, short verilog and vhdl questions > have been tolerated in comp.arch.fpga. Actually, my question is not about VHDL, it is about the utility of a left shift operator that copies the lsb. Or perhaps I should say the rightmost bit. As HK pointed out, the right bit and the lsb are not always synonymous. So I guess that answers my question of why this operator might be used. I have a bias for lsb being the "right hand" bit as well as the zeroth bit. I remember working with CDC documentation that used 0 to label the msb (on the left). That was the first time I had seen bits numbered that way and thought these guys must be pretty strange. I still have not seen an explanation of why that convention would be adopted, but then the limeys all drive on the left too! So go figure! I would suggest that FPGAs enforce rightmost bits being the lsb as well as labeled with a 0. That can be done in hardware, right? ;^) But you suggest that I should use instead the numeric standard function shift_left as it does the "right thing" for both types of operands. I see that there is little difference between shift_left and sll. function SHIFT_LEFT (ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED; -- Result subtype: UNSIGNED(ARG'LENGTH-1 downto 0) -- Result: Performs a shift-left on an UNSIGNED vector COUNT times. -- The vacated positions are filled with '0'. -- The COUNT leftmost elements are lost. function SHIFT_LEFT (ARG: SIGNED; COUNT: NATURAL) return SIGNED; -- Result subtype: SIGNED(ARG'LENGTH-1 downto 0) -- Result: Performs a shift-left on a SIGNED vector COUNT times. -- The vacated positions are filled with '0'. -- The COUNT leftmost elements are lost. It seems to be that they are doing the same thing... In fact, the one difference you might expect if you were using a singed operand is to not clobber the sign bit, but that is not prevented. So I fail to see why shift_left would have been added to the standard. Again, I expect if they were adding a shift_right, they needed a shift_left to fill the hole. In contrast the right_shift operator does handle the sign bit. I think someone fell down on the job with this one... or maybe not. If the result of a left shift on a signed number changes the sign bit, it would be an overflow anyway. So I guess it's all good! RickArticle: 143183
rickman wrote:
> It seems to be that they are doing the same thing...
It depends on the type of arg:
-- Id: S.1
function shift_left ( ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED;
-- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0)
-- Result: Performs a shift-left on an UNSIGNED vector COUNT times.
-- The vacated positions are filled with Bit '0'.
-- The COUNT leftmost bits are lost.
-- Id: S.3
function shift_left ( ARG: SIGNED; COUNT: NATURAL) return SIGNED;
-- Result subtype: SIGNED (ARG'LENGTH-1 downto 0)
-- Result: Performs a shift-left on a SIGNED vector COUNT times.
-- All bits of ARG, except ARG'LEFT, are shifted left COUNT times.
-- The vacated positions are filled with Bit '0'.
-- The COUNT leftmost bits, except ARG'LEFT, are lost.
----------------
Article: 143184rickman <gnuarm@gmail.com> wrote: < On Sep 23, 6:11?pm, Mike Treseler <mtrese...@gmail.com> wrote: (snip) <> sla shifts left and copies the right bit. (snip) < Actually, my question is not about VHDL, it is about the utility of a < left shift operator that copies the lsb. Or perhaps I should say the < rightmost bit. I do agree that is unusual, at least as an arithmetic operation. < As HK pointed out, the right bit and the lsb are not < always synonymous. So I guess that answers my question of why this < operator might be used. I have a bias for lsb being the "right hand" < bit as well as the zeroth bit. I only have verilog references, and have only written verilog. I can usually read VHDL, though. Verilog allows one to number the bits in either order. reg [3:0] i; reg [0:3] j; If you assign between such, the assignment is in left to right order, not in numerical order. < I remember working with CDC documentation that used 0 to label the msb < (on the left). That was the first time I had seen bits numbered that < way and thought these guys must be pretty strange. I still have not < seen an explanation of why that convention would be adopted, but then < the limeys all drive on the left too! So go figure! IBM S/360 and successor (and probably predecessors) numbers the MSB as bit 0. That is consistent with big endian byte order. (Some IBM processors were pretty much bit addressable, so that could have been important. S/360 is not, so the convention is only in the documentation.) It made things interesting with the 64 bit extension of z/Architecture. 32 bit instructions operate on the low half of the 64 bit registers, now bits 32 to 63. < I would suggest that FPGAs enforce rightmost bits being the lsb as < well as labeled with a 0. That can be done in hardware, right? ;^) That is a strange comment. FPGAs don't enforce anything. One can number (or letter) the bits anyway one wants, the FPGA just supplying a collection of logic. I don't know about VHDL but, as I said, verilog does not force one convention or the other. -- glenArticle: 143185
The VHDL numeric_std package does not force bit 0 = LSB. 'Left is always MSB. Not sure about the new fixed point types... AndyArticle: 143186
rickman <gnuarm@gmail.com> wrote: > I remember working with CDC documentation that used 0 to label the msb > (on the left). That was the first time I had seen bits numbered that > way and thought these guys must be pretty strange. I still have not > seen an explanation of why that convention would be adopted, but then > the limeys all drive on the left too! So go figure! HP historically did this too with PA-RISC and earlier architectures. In a big-endian world it can vaguely make sense as everything is read from left to right with increasing addresses. Of course can anyone use the words "left" and "right" without at least considering that the whole thing is a bit mad really. G.Article: 143187
I have been using ispLever on this machine for over a year now. I just tried running a compile and I got an error message saying "Can't read the ini file". This comes up 7 times as I click the error box away. I restarted the tool and get this error before it comes up and in fact, it never comes up. I've rebooted the machine and still get the error and the tool won't start. Anyone know what causes this? I assume it is a corrupt file, but all it says is "ini file". I guess I'll have to contact support tomorrow. Geeze, I guess I should have reupped the formal support plan. I'd hate for them to blow me off on this issue. RickArticle: 143188
On Sep 24, 6:28=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > rickman wrote: > > It seems to be that they are doing the same thing... > > It depends on the type of arg: > > =A0 =A0 =A0-- Id: S.1 > =A0 =A0function shift_left =A0( =A0ARG: UNSIGNED; COUNT: NATURAL) return = UNSIGNED; > =A0 =A0 =A0 -- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0) > =A0 =A0 =A0 -- Result: Performs a shift-left on an UNSIGNED vector COUNT = times. > =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The vacated positions are filled with Bit = '0'. > =A0 =A0 =A0 -- The COUNT leftmost bits are lost. > > =A0 =A0 =A0 -- Id: S.3 > =A0 =A0function shift_left =A0( =A0ARG: SIGNED; COUNT: NATURAL) return SI= GNED; > =A0 =A0 =A0 -- Result subtype: SIGNED (ARG'LENGTH-1 downto 0) > =A0 =A0 =A0 -- Result: Performs a shift-left on a SIGNED vector COUNT tim= es. > =A0 =A0 =A0 -- =A0 =A0All bits of ARG, except ARG'LEFT, are shifted left = COUNT times. > =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The vacated positions are filled with Bit = '0'. > =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The COUNT leftmost bits, except ARG'LEFT, = are lost. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 ---------------- Why does your copy of this differ from mine? You snipped my quote of these functions, but they are very different. Still, the fact remains that it really doesn't matter. If you shift the entire number and the new value of the sign bit has changed, it was an overflow. Even if you don't shift the sign bit, it is still an overflow. I checked the file I read and it is dated 1995. I guess they redefined the signed left shift at some point. I wonder if that caused anyone any trouble??? RickArticle: 143189
On Sep 24, 6:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > < I would suggest that FPGAs enforce rightmost bits being the lsb as > < well as labeled with a 0. =A0That can be done in hardware, right? =A0;^= ) > > That is a strange comment. =A0FPGAs don't enforce anything. =A0One can > number (or letter) the bits anyway one wants, the FPGA just supplying > a collection of logic. =A0I don't know about VHDL but, as I said, > verilog does not force one convention or the other. You clearly didn't see the smiley... RickArticle: 143190
On Sep 23, 5:47=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote: > rickman wrote: > > That is what I was taught was the way to perform an arithmetic left > > shift, to fill the right positions with zero. =A0But this is also the > > logical left shift operation. =A0I don't understand why a left shift > > which fills the right most positions with the former lsb would be of > > value. =A0I suppose it could just exist to fill the space in a chart, > > but calling it an arithmetic left shift is a misnomer as arithmetic > > would use the same shift as the logical left shift. > > But only because you suppose that the MSB is on the left side > and the LSB on the right side. Yeah, I guess it also depends on which side you consider to be the right! RickArticle: 143191
On Sep 22, 10:19=A0pm, nobody <cydrollin...@gmail.com> wrote: > Looking for interest in an Open Source Hardware USB programmable FPGA, > XC3S250E. I have been having some difficulty getting the right people > exposed to this project. If you have any interest in this project > would like to hear from you. It is headed into an Open Source Hardware > agreement therefore their is no proprietary information about the > design. > > Here is an image of the board.http://www.mediafire.com/imageview.php?quic= kkey=3Dyhjjddznzmx&thumb=3D5 > > Cy Drollinger > Electronic Realization L.L.C. > 313 W. Mendenhall #5 > Bozeman, MT 59715 > PH: 406-586-5502 > Email: c...@montana.net Cy does your company have a permananet web url? or the product actually, i am writing september brain adding the photo of you gadet too (with commentary) would be nice to add link too - i will defenetly NOT link to mediafire or something similar AnttiArticle: 143192
On Sep 24, 5:39=A0pm, Matthieu Michon <matthieu.d.u.m.m.y.mic...@gmail.com> wrote: > On Thu, 24 Sep 2009 01:28:11 -0700 (PDT) > > "nic_o_...@msn.com" <nic_o_...@msn.com> wrote: > > (...) > > I always use an asynchronous reset description in my processes but the > > actual reset signal is synchronized in another block. > > I only posted the offending entity, the design is larer than this > > single file. > > > I am no beginner and I did simulate my design before synthesizing it. > > Simulation runs absolutely fine. > > I have made further investigation, the SPI master generates the > > correct number of clock cycles but only the 12 first bits are > > transmitted, MOSI then goes high. > > > Nicolas > > In the case of a discrepancy in the behavior between simulation and execu= tion, I would check the usuals : > =A0- Synthesis and implementation transcript for anything even remotely s= uspicious (while focusing manly on the logic optimization and timing). > =A0- Reset signal synchronization is performed against the _correct_ cloc= k net. > =A0- RTL and physical (low-level) FPGA implementation of your design. > > While you may not have access to the JTAG interface of the FPGA (o/w I gu= ess you'd already have used chipscope to probe the revelant nets), you can = always throw a post p/r simulation, just to make sure that the toolchain di= dn't caught its feet in the rug while implementing your design. > > Hope this helps. > > -- > Matthieu Michon It seems that it was related to the "Map Slice Logic into Unused Block RAMs" option that was enabled from a previous project I copied the tcl script from. NicolasArticle: 143193
On Thu, 24 Sep 2009 17:49:27 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >On Sep 24, 6:28 pm, Mike Treseler <mtrese...@gmail.com> wrote: >> rickman wrote: >> > It seems to be that they are doing the same thing... >> >> It depends on the type of arg: >> >> -- Id: S.1 >> function shift_left ( ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED; >> -- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0) >> -- Result: Performs a shift-left on an UNSIGNED vector COUNT times. >> -- The vacated positions are filled with Bit '0'. >> -- The COUNT leftmost bits are lost. >> >> -- Id: S.3 >> function shift_left ( ARG: SIGNED; COUNT: NATURAL) return SIGNED; >> -- Result subtype: SIGNED (ARG'LENGTH-1 downto 0) >> -- Result: Performs a shift-left on a SIGNED vector COUNT times. >> -- All bits of ARG, except ARG'LEFT, are shifted left COUNT times. >> -- The vacated positions are filled with Bit '0'. >> -- The COUNT leftmost bits, except ARG'LEFT, are lost. >> ---------------- > >Why does your copy of this differ from mine? You snipped my quote of >these functions, but they are very different. Still, the fact remains >that it really doesn't matter. If you shift the entire number and the >new value of the sign bit has changed, it was an overflow. Even if >you don't shift the sign bit, it is still an overflow. > >I checked the file I read and it is dated 1995. I guess they >redefined the signed left shift at some point. I wonder if that >caused anyone any trouble??? Or was it a documentation error of the cut/paste variety, later corrected? I would think this more likely than an actual change in behaviour. If you look at the associated package body (usually a second file) the source code should make it clear what the function really does. - BrianArticle: 143194
Frank Buss wrote: > Antti.Lukats@googlemail.com wrote: > >> hm if that is the easy way, what is the hard way? > > The hard way would be to use two different VHDL files and compare the > bitstreams :-) > I think that's the medium difficulty way, Frank. The hard way is to etch off the packaging and metal/silicon layers with HF while looking at the die under an electron microscope to reverse engineer the silicon. While standing on one leg. Cheers, Syms.Article: 143195
Normally ispLever installs the *.ini files to c:\lsc_env. You can change
this by setting the variable LSC_INI_PATH to something like
%USERPROFILE%\lsc_env
If yours has become screwed up somehow, you can write your own based on
the one below (from German windows Server 2003):
Store it under lsc_7_2.ini in whichever lsc_env directory you decide to
use original or one pointed to by LSC_INI_PATH).
Sorry, but I can't restrain myself on my favorite rant here. The big
problem is the cluelessness of so many windows SW developers who still
have not realised that computers in the 21th century are largely
multi-user or at least that the SW should support that model. Putting
one config file for everbody in a privately invented directory should
have died out around 1990. It would be a great help to the user if these
developers took the time to look at the windows API and read the section
Win32 and Com Development -> Administration and Management
-> Policies and Profiles
(Now, I'm feeling better)
[paths]
Bin=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
Config=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\config
Examples=C:\Programme\Lattice\ispTOOLS7_2\examples
FPGAPath=C:\Programme\Lattice\ispTOOLS7_2\ispfpga
FPGABinPath=C:\Programme\Lattice\ispTOOLS7_2\ispfpga\bin\nt
INI=C:\lsc_env
License=C:\Programme\Lattice\ispTOOLS7_2\license
Root=C:\Programme\Lattice\ispTOOLS7_2\ispcpld
ispVM=C:\Programme\Lattice\ispTOOLS7_2\ispvmsystem
SpectrumPath="C:\isptools\spectrum"
PrecisionPath=""
ModelsimPath=""
SynplifyPath=C:\Programme\Lattice\ispTOOLS7_2\synpbase
MachPath=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
AppNotes=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
PDSPath=C:\Programme\Lattice\ispTOOLS7_2\ispcomp
Tutorial=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\tutorial
Manuals=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\manuals
DSPPATH=C:\Programme\Lattice\ispTOOLS7_2\ispLeverDSP
TclPath=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\tcltk\bin
ActiveHDLPath=C:\Programme\Lattice\ispTOOLS7_2\active-hdl\bin
[Strings]
ProductName=ispLEVER
ProductPrefix=SYN
ProductTitle=ispLEVER
ProductVersion=7.2.00.07
ProductType=7.2.00.41.49.08_LS_HDL_BASE_PC_N
ProgramFolder=Lattice Semiconductor 7.2
[CPLD]
[FPGA]
LSCC_DEV_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_RDD_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_LIB_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_LCI_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\config
LSDB_COMPRESSED = "1"
[Packages]
LatticeGNUCompiler=C:\Programme\Lattice\ispTOOLS7_2\micosystem
LatticeMico32System=C:\Programme\Lattice\ispTOOLS7_2\micosystem
Synplify=C:\Programme\Lattice\ispTOOLS7_2\synpbase
Spectrum="C:\isptools\spectrum"
Precision=""
ModelSim=""
ispVMSystem=C:\Programme\Lattice\ispTOOLS7_2\ispvmsystem
HDLExplorer=C:\Programme\Lattice\ispTOOLS7_2\hdle\win32
EPICPATH=C:\Programme\Lattice\ispTOOLS7_2\ispfpga\bin\nt
LM32PATH="C:\isptools\micosystem"
ActiveHDL=C:\Programme\Lattice\ispTOOLS7_2\active-hdl\bin
[Symbols]
DeviceFamily=ORCALDB5_JED_T_VHD
ProjectType=Device
ToolMenu=ORCATLM32REVEAL
CurrentProject=C:\Dokumente und Einstellungen\Administrator\Eigene
Dateien\Lattice\pcie_easi.syn
EntryType=Pure VHDL
FlowType=NORMAL
Simulator=ActiveHDL
RevealInsert=false
UseDefinedSymbols=c:\dokumente und einstellungen\administrator\eigene
dateien\lattice\pcie_easi.ini
Article: 143196
I'm currently debugging a design with a Xilinx FX20 FPGA and 2
MT46V16M16BG-6 DDR chips. When writing a series of test patterns to
the memory and reading it back I get some strange results:
Writing a series of test patterns at byte addresses 0,4,8...
Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000004
Writing 22222222 at 00000008
Writing 33333333 at 0000000C
Writing 44444444 at 00000010
Writing 55555555 at 00000014
Writing 66666666 at 00000018
Writing 77777777 at 0000001C
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,
11111111
You can see that 0x0 and 0x4 write and read correctly, but the
subsequent writes to 0x8, 0xC, 0x10, 0x14, 0x18, 0x1C are all
duplicates of the first set.
If I change the writes to multiples of 8 (0x0, 0x8, 0x10, 0x18, 0x20,
0x28, 0x30, 0x38) I get the following output:
Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000008
Writing 22222222 at 00000010
Writing 33333333 at 00000018
Writing 44444444 at 00000020
Writing 55555555 at 00000028
Writing 66666666 at 00000030
Writing 77777777 at 00000038
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,DEADBEEF,DEADBEEF,DEADBEEF,
44444444,44444444,44444444,44444444
Step size of 16:
Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000010
Writing 22222222 at 00000020
Writing 33333333 at 00000030
Writing 44444444 at 00000040
Writing 55555555 at 00000050
Writing 66666666 at 00000060
Writing 77777777 at 00000070
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,DEADBEEF,
22222222,22222222,44444444,44444444,66666666,66666666
And if I again change the multiples to 32, everything works.
Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000020
Writing 22222222 at 00000040
Writing 33333333 at 00000060
Writing 44444444 at 00000080
Writing 55555555 at 000000A0
Writing 66666666 at 000000C0
Writing 77777777 at 000000E0
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Read and writes match
I thought maybe it was a trace or two on the board that might be bad
(tied to another, not the correct length), but I exchanged address
lines with higher ones and got the same results. I.e.
Original
FPGA Address DDR Address
0 0
1 1
2 2
Exchanged
0 0
1 3
2 4
Any insight would be greatly appreciated.
Thanks!
Article: 143197On Sep 25, 8:42=A0am, George <bishop...@gmail.com> wrote: > I'm currently debugging a design with a Xilinx FX20 FPGA and 2 > MT46V16M16BG-6 DDR chips. =A0When writing a series of test patterns to > the memory and reading it back I get some strange results: > > Writing a series of test patterns at byte addresses 0,4,8... > Testing Tap 27,Regfile 50000000 > Writing DEADBEEF at 00000000 > Writing 11111111 at 00000004 > Writing 22222222 at 00000008 > Writing 33333333 at 0000000C > Writing 44444444 at 00000010 > Writing 55555555 at 00000014 > Writing 66666666 at 00000018 > Writing 77777777 at 0000001C > Wr:DEADBEEF, > 11111111,22222222,33333333,44444444,55555555,66666666,77777777 > Rd:DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF, > 11111111 > > You can see that 0x0 and 0x4 write and read correctly, but the > subsequent writes to 0x8, 0xC, 0x10, 0x14, 0x18, 0x1C are all > duplicates of the first set. > > If I change the writes to multiples of 8 (0x0, 0x8, 0x10, 0x18, 0x20, > 0x28, 0x30, 0x38) I get the following output: > > Testing Tap 27,Regfile 50000000 > Writing DEADBEEF at 00000000 > Writing 11111111 at 00000008 > Writing 22222222 at 00000010 > Writing 33333333 at 00000018 > Writing 44444444 at 00000020 > Writing 55555555 at 00000028 > Writing 66666666 at 00000030 > Writing 77777777 at 00000038 > Wr:DEADBEEF, > 11111111,22222222,33333333,44444444,55555555,66666666,77777777 > Rd:DEADBEEF,DEADBEEF,DEADBEEF,DEADBEEF, > 44444444,44444444,44444444,44444444 > > Step size of 16: > > Testing Tap 27,Regfile 50000000 > Writing DEADBEEF at 00000000 > Writing 11111111 at 00000010 > Writing 22222222 at 00000020 > Writing 33333333 at 00000030 > Writing 44444444 at 00000040 > Writing 55555555 at 00000050 > Writing 66666666 at 00000060 > Writing 77777777 at 00000070 > Wr:DEADBEEF, > 11111111,22222222,33333333,44444444,55555555,66666666,77777777 > Rd:DEADBEEF,DEADBEEF, > 22222222,22222222,44444444,44444444,66666666,66666666 > > And if I again change the multiples to 32, everything works. > > Testing Tap 27,Regfile 50000000 > Writing DEADBEEF at 00000000 > Writing 11111111 at 00000020 > Writing 22222222 at 00000040 > Writing 33333333 at 00000060 > Writing 44444444 at 00000080 > Writing 55555555 at 000000A0 > Writing 66666666 at 000000C0 > Writing 77777777 at 000000E0 > Wr:DEADBEEF, > 11111111,22222222,33333333,44444444,55555555,66666666,77777777 > Rd:DEADBEEF, > 11111111,22222222,33333333,44444444,55555555,66666666,77777777 > Read and writes match > > I thought maybe it was a trace or two on the board that might be bad > (tied to another, not the correct length), but I exchanged address > lines with higher ones and got the same results. =A0I.e. > > =A0 =A0 =A0 =A0 Original > =A0 =A0 FPGA Address =A0 =A0 =A0 =A0DDR Address > =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A00 > =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A01 > =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A02 > > =A0 =A0 =A0 =A0 Exchanged > =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A00 > =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A03 > =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A04 > > Any insight would be greatly appreciated. > > Thanks! With 2 16-bit chips, a "word" internal to the FPGA would actually be 64 bits, not 32. So in the first case it looks like you read the same "word" over and over probably for a full burst. You didn't say what burst size you use or even which controller (MIG? MPMC?) In any case it is possible that the burst size of the device is not set properly during start-up, causing a full burst to be only a single "word", while the controller expects it to be 4 words. This could cause the symptoms you see. By the way you can't re-arrange the address lines unless you also move the mode register bits around to match the lines. The address lines are effectively the data bits for mode register loads. I would check to see what you have programmed in the mode register to make sure it matches your expectations. Regards, GaborArticle: 143198
I'm using the mpmc controller. I thought the burst size of the ddr was 4 words, and I don't see any way to change this in the mpmc interface. Thanks, GeorgeArticle: 143199
On Sep 25, 9:39=A0am, George <bishop...@gmail.com> wrote: > I'm using the mpmc controller. =A0I thought the burst size of the ddr > was 4 words, and I don't see any way to change this in the mpmc > interface. > > Thanks, > George Sorry, I retract that previous statement. I see in the datasheet that the burst length can be programmed to 2,4,or 8.
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