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
Why not learn how to Google?! :-) "Don't Burn Your Bridges" site:xilinx.com HTH, Syms. p.s. This might help you next time:- http://catb.org/esr/faqs/smart-questions.htmlArticle: 112926
Hi
I'm just doing my first steps trying to get a busmaster
example created with xps running. There is some example code
and i just tried to use it for the first test. However it just
refuses to work and the busybit of the busmaster seems to stay
set. Has anybody an idea?
Thanks
ST
my c code:
int main (void) {
Xuint64 *ptr;
int i;
volatile unsigned int a=1;
unsigned char *control_register=(unsigned char*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x100;
unsigned char *status_register=(unsigned char*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x101;
unsigned int *ip2ip_addr=(unsigned int*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x104;
unsigned int *ip2bus_addr=(unsigned int*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x108;
unsigned int *transfer_length=(unsigned int*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x10c;
unsigned char *byte_enable=(unsigned char*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x10e;
unsigned char *go=(unsigned char*)XPAR_TEST_BUSMASTER_0_BASEADDR+0x10f;
print("-- Entering main() --\r\n");
while(*status_register & 0x40) ; //wait for busmaster to be ready
ptr=(Xuint64*)XPAR_TEST_BUSMASTER_0_BASEADDR;
ptr->Lower=0x1234;
ptr->Upper=0x5678;
*control_register=0x40;
*ip2ip_addr=(unsigned int*)XPAR_TEST_BUSMASTER_0_BASEADDR;
*ip2bus_addr=&a;
*transfer_length=0x0004;
*byte_enable=0x00ff;
*go=0x0a;
print("busmaster transfer\r\n");
for(i=0;i<1000;i++) while(*status_register & 0x40) ; //wait for busmaster to be not busy anymore
if(ptr->Lower==1) print("success");
else print("failure");
print("-- Exiting main() --\r\n");
return 0;
}
This corresponds to the documentation in user_logic.vhd:
------------------------------------------
-- Example code to demonstrate user logic master model functionality
--
-- Note:
-- The example code presented here is to show you one way of stimulating
-- the IPIF IP master interface under user control. It is provided for
-- demonstration purposes only and allows the user to exercise the IPIF
-- IP master interface during test and evaluation of the template.
-- This user logic master model contains a 16-byte flattened register and
-- the user is required to initialize the value to desire and then write to
-- the model's 'Go' port to initiate the user logic master operation.
--
-- Control Register (C_BASEADDR + OFFSET + 0x0):
-- bit 0 - Rd (Read Request Control)
-- bit 1 - Wr (Write Request Control)
-- bit 2 - BL (Bus Lock Control)
-- bit 3 - Brst (Burst Assertion Control)
-- bit 4-7 - Spare (Spare Control Bits)
-- Status Register (C_BASEADDR + OFFSET + 0x1):
-- bit 0 - Done (Transfer Done Status)
-- bit 1 - Bsy (User Logic Master is Busy)
-- bit 2-7 - Spare (Spare Status Bits)
-- IP2IP Register (C_BASEADDR + OFFSET + 0x4):
-- bit 0-31 - IP2IP Address (This 32-bit value is used to populate the
-- IP2IP_Addr(0:31) address bus during a Read or Write user
-- logic master operation)
-- IP2Bus Register (C_BASEADDR + OFFSET + 0x8):
-- bit 0-31 - IP2Bus Address (This 32-bit value is used to populate the
-- IP2Bus_Addr(0:31) address bus during a Read or Write user
-- logic master operation)
-- Length Register (C_BASEADDR + OFFSET + 0xC):
-- bit 0-15 - Transfer Length (This 16-bit value is used to specify the
-- number of bytes (1 to 65,536) to transfer during user logic
-- master read or write operations)
-- BE Register (C_BASEADDR + OFFSET + 0xE):
-- bit 0-7 - IP2Bus master BE (This 8-bit value is used to populate the
-- IP2Bus_MstBE byte enable bus during user logic master read or
-- write operations, only used in single data beat operation)
-- Go Register (C_BASEADDR + OFFSET + 0xF):
-- bit 0-7 - Go Port (A write to this byte address initiates the user
-- logic master transfer, data key value of 0x0A must be used)
--
-- Note: OFFSET may be different depending on your address space configuration,
-- by default it's either 0x0 or 0x100. Refer to IPIF address range array
-- for actual value.
-- Here's an example procedure in your software application to initiate a 4-byte
-- write operation (single data beat) of this master model:
-- 1. write 0x40 to the control register
-- 2. write the source data address (local) to the ip2ip register
-- 3. write the destination address (remote) to the ip2bus register
-- - note: this address will be put on the target bus address line
-- 4. write 0x0004 to the length register
-- 5. write valid byte lane value to the be register
-- - note: this value must be aligned with ip2bus address
-- 6. write 0x0a to the go register, this will start the write operation
Article: 112927Hi, Does anyone have a copy of the latest USB cable firmware version 1025 (the latest according to http://www.xilinx.com/support/programr/usb_history.htm). This file is necessary for use with 2.6 linux kernels and would be in /etc/hotplug/usb/xusbdfwu.fw. The version on the Xilinx website seems to be broken. Xilinx support acknowledge this but are taking some time to get back to me with the file. I need to get this up an running urgently, so I would be grateful if someone who has the USB cable working could just send me their firmware file! Many thanks, RobArticle: 112928
Hi.
We are working on a Virtex4 FX12 PowerPC system. The code below is stored
in BRAM and so are the stack and heap.
Using cache on the external memory crashes the program after approx.
10000 checks. When only caching BRAM it works fine.
The program below clears the memory, then it checks half the memoryspace
for zeros and writes the addresses of the zeros in the other half.
Any sugestions why caching of external memory doesn't work?
/////// CODE ////////////////////
#define CHECK_BASE_ADDR XPAR_DDR_SDRAM_32MX16_MEM0_BASEADDR
#define CHECK_HIGH_ADDR (WRITE_BASE_ADDR-1)
#define WRITE_BASE_ADDR (XPAR_DDR_SDRAM_32MX16_MEM0_BASEADDR+0x02000000)
#define WRITE_HIGH_ADDR XPAR_DDR_SDRAM_32MX16_MEM0_HIGHADDR
Xuint32* CheckPtr = (Xuint32*)CHECK_BASE_ADDR;
Xuint32* WritePtr = (Xuint32*)WRITE_BASE_ADDR;
int main (void) {
ClearMemory();//write zeros at all memory locations
XCache_EnableICache(0x00000001);
XCache_EnableDCache(0x80000001);
while(1)
{
if(*CheckPtr==0)
{
*WritePtr = CheckPtr;
if(++WritePtr > WRITE_HIGH_ADDR)
WritePtr = WRITE_BASE_ADDR;
}
if(++CheckPtr > CHECK_HIGH_ADDR)
CheckPtr = CHECK_BASE_ADDR;
}
}
Article: 112929As Mike suggested, I would check to see if I am using the same device and speed-grade as in the book. Typically, the timing parameters that you are interested in are constant for a particular device and speed-grade in that device. So they would be published in the datasheet. In quartus you can try the property editor. Nevertheless, the timing analyzer already includes these values in its cell delay component. So no matter what you find out from the datasheet it would not change the timing. Also, in the timing analyzer report you can get an idea where most of your delays are coming from... if the IC delay is greater that 75%, you probably have some thing else going on that causes the logic to be placed too far away. It could also be that the clock is not routed on a global route. -sanjay fl wrote: > Hi, I still cannot get better performance, even for your code. The > following is part of the info in listpath. Why there is so much IC and > CELL delay? Could you guess that? I doubt there are some settings I > must set besides fmax setting. Thank you very much. > > > Info: Clock "clk" has Internal fmax of 59.52 MHz between source > register "\only:x_v[0]" and destination register "\only:sum_v[14]" > (period=3D 16.8 ns) > Info: + Longest register to register delay is 13.200 ns > Info: 1: + IC(0.000 ns) + CELL(0.000 ns) =3D 0.000 ns; Loc. =3D LC6_F16; > Fanout =3D 2; REG Node =3D '\only:x_v[0]' > Info: 2: + IC(2.200 ns) + CELL(1.200 ns) =3D 3.400 ns; Loc. =3D LC1_F13; > Fanout =3D 2; COMB Node =3D > 'lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cout[0]' > Info: 3: + IC(0.000 ns) + CELL(0.300 ns) =3D 3.700 ns; Loc. =3D LC2_F13; > Fanout =3D 2; COMB Node =3D > 'lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cout[1]' > > > > Mike Treseler a =E9crit : > > > fl wrote: > > > Thank you, Mike. You are so kind. I get the same fmax, i.e. 59.52 MHz > > > (period=3D16.8 ns). fmax is the same even though I constraint fmax to= 75 > > > MHz in the dialog box Clock Settings: Default required fmax: 75 MHz. > > > The slack is -3.467 ns. The device is FLEX10K: EPF10K20RC240-4. > > > Because the result of fmax is the same, there may be something wrong = in > > > the utilization of Quartus II 6.0 webpack, Windows XP. > > > > > > Or maybe the author was using a faster speed grade > > or a different device. > > With an epm240f100c4 I got 197.51 MHz ( period =3D 5.063 ns ) > > > > In any case, I think he was doing it the hard way. > > Good luck. > >=20 > > -- Mike TreselerArticle: 112930
"Austin Lesea" <austin@xilinx.com> wrote in message news:eknjcj$sv63@cnn.xsj.xilinx.com... > Andrew, > > Yes, the taps are only 10 ps apart, but the control required to generate > any M/D of the input clock is unable to be perfect for the DCM DFS output. > > I refer to the algorithm as a "tap dance." > > One creates a tapped ring oscillator out of the tapped delay line. If > the output frequency is greater than the M/D times the input frequency, > the period is made longer by changing taps. In the same way if the > frequency is lower than the optimal value, the tap is moved to a shorter > point. > > In order to know that the frequency is high or low, one requires a > frequency detector, which means you have to integrate time (count, and > wait). Once you have your answer, it is too late to do anything that > will correct right away, and you can only nudge towards the proper rate. > > The DCM DFS uses a fairly sophisticated prediction method to drop/add > tap changes as appropriate (reference the patents if interested), but > yet is still not able to get the tap precision as the dominant jitter > contributor. Rather, the DCM output jitter on the synthesized frequency > output is mostly from not knowing when to zig, or zag, combined with > jitter from the clock in, and not being perfectly accurate in knowing if > the frequency is larger, or smaller (you sometimes make a mistake, > unavoidably, because you can't wait too long! but you must wait to know > anything at all). > > The DCM DLL outputs do have a much more well behaved and bounded jitter > output, which is precisely 5 steps (at most) in jitter plus your input > clock jitter, as you are either one high, or one low, or you are two > high (because your phase detector guessed wrong), or two low (again > because a phase detector in the presence of jitter is also an imperfect > arbiter). > > Austin Nice explanation, Austin, but did not answer the OP's question about how to get the tools to include the appropriate jitter in the static timing analysis. It's an important question. Do you know of any Xilinx guidelines that cover this topic in detail? RobArticle: 112931
Hi, Just a suggestion. Does quartus allow user to play around the optimization cost during its physical synthesis stage? Best regards, ABC fpgabuilder wrote: > As Mike suggested, I would check to see if I am using the same device > and speed-grade as in the book. Typically, the timing parameters that > you are interested in are constant for a particular device and > speed-grade in that device. So they would be published in the > datasheet. In quartus you can try the property editor. Nevertheless, > the timing analyzer already includes these values in its cell delay > component. So no matter what you find out from the datasheet it would > not change the timing. > > Also, in the timing analyzer report you can get an idea where most of > your delays are coming from... if the IC delay is greater that 75%, you > probably have some thing else going on that causes the logic to be > placed too far away. It could also be that the clock is not routed on > a global route. > > -sanjay > > fl wrote: > > Hi, I still cannot get better performance, even for your code. The > > following is part of the info in listpath. Why there is so much IC and > > CELL delay? Could you guess that? I doubt there are some settings I > > must set besides fmax setting. Thank you very much. > > > > > > Info: Clock "clk" has Internal fmax of 59.52 MHz between source > > register "\only:x_v[0]" and destination register "\only:sum_v[14]" > > (period=3D 16.8 ns) > > Info: + Longest register to register delay is 13.200 ns > > Info: 1: + IC(0.000 ns) + CELL(0.000 ns) =3D 0.000 ns; Loc. =3D LC6_F= 16; > > Fanout =3D 2; REG Node =3D '\only:x_v[0]' > > Info: 2: + IC(2.200 ns) + CELL(1.200 ns) =3D 3.400 ns; Loc. =3D LC1_F= 13; > > Fanout =3D 2; COMB Node =3D > > 'lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cout[0]' > > Info: 3: + IC(0.000 ns) + CELL(0.300 ns) =3D 3.700 ns; Loc. =3D LC2_F= 13; > > Fanout =3D 2; COMB Node =3D > > 'lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cout[1]' > > > > > > > > Mike Treseler a =E9crit : > > > > > fl wrote: > > > > Thank you, Mike. You are so kind. I get the same fmax, i.e. 59.52 M= Hz > > > > (period=3D16.8 ns). fmax is the same even though I constraint fmax = to 75 > > > > MHz in the dialog box Clock Settings: Default required fmax: 75 MHz. > > > > The slack is -3.467 ns. The device is FLEX10K: EPF10K20RC240-4. > > > > Because the result of fmax is the same, there may be something wron= g in > > > > the utilization of Quartus II 6.0 webpack, Windows XP. > > > > > > > > > Or maybe the author was using a faster speed grade > > > or a different device. > > > With an epm240f100c4 I got 197.51 MHz ( period =3D 5.063 ns ) > > > > > > In any case, I think he was doing it the hard way. > > > Good luck. > > >=20 > > > -- Mike TreselerArticle: 112932
Did you use a simulation model for you memory module?Article: 112933
Rob, No, I am not a tools expert (and really can't comment on constraints for timing). And I think the other posting to just email in a webcase is the best advice. AustinArticle: 112934
backhus wrote: > Hans schrieb: > > "Weng Tianxiang" <wtxwtx@gmail.com> wrote in message > > news:1164938845.207923.209380@79g2000cws.googlegroups.com... > >> Hi, > >> Our hardware engineer got *.vcd file from Xilinx ChipScope, then I > >> swithced the *.vcd file to *.wlf file in ModelSim using vcd2wlf > >> command. After getting *.wlf file, I combined a lot of signals, added > >> color, changed their display format and so on. After that I would like > >> to save the file for later use. But I couldn't find any appropriate > >> tools in ModelSim to save the *.wlf file. > >> > >> The only file that can be exported from ModelSim is *.bmp. > >> > >> Do you know any better method? > >> > >> Thank you. > >> > >> Weng > >> > > > > Using 6.2d, log signals, run your simulation, select the workspace window go > > to file and hit the save option.... alternative have a look in the user > > manual :-) > > > > Hans > > www.ht-lab.com > > > > > Hi Hansn and Weng, > unless the 6.2d version is different in that point, all versions of > Modelsim I know just save the format information in a do-file when using > the file->save menu entry. > > Of course it can be helpful, when it's ok to live with 2 files. > The original vcd-file, and the format do-file (manually extended with > the vcd2wlf comand at the top of the file.). My understanding of Wengs > question is, that he wants to save everything in one file, and expects > the wlf-file to do the trick. > > For saving the wlf-file there used to be a "Save Dataset" command in the > File menu. I didn't find it in 6.0d anymore. But even then I think you > need 2 files, because the wlf-file only contains the bare data of the > simulated signals and knows nothing about signal combinations, colors, > cursors etc.. But I may be wrong... > > Have a nice Simulation > Eilert Hi Eilert, What you said is what I wanted. Hans said 6.2 version, but I have only 6.1x version where there is no "Save Dataset" command any more. I can live up to 2 files, one is *.wlf, another is *.do, but after loading *.do file, how can you load data from *.wlf file? The data is generated by running a simulation, but by loading from *.wlf. You are very appreciated If you can tell me how to load *.wlf file with opend *.do file. Weng For 5.x version it really had "Save Dataset" option when open "File/Save" manu. WengArticle: 112935
glen herrmannsfeldt wrote:
> I first heard about metastability in a discussion about the PDP-10
> (KA10), which apparently had no metastability problem. The solution
> to metastability is asynchronous logic (also called self-timed logic).
The D-flop is also an asynchronous circuit.
-- Mike Treseler
Article: 112936Mike Treseler wrote: > glen herrmannsfeldt wrote: > >> I first heard about metastability in a discussion about the PDP-10 >> (KA10), which apparently had no metastability problem. The solution >> to metastability is asynchronous logic (also called self-timed logic). > > The D-flop is also an asynchronous circuit. > > -- Mike Treseler It's amusing that there is, in the strictest sense, no such thing as a completely synchronous circuit. Indeed, it is the asynchronous nature of a FF that is the root cause of metastability ;) Cheers PeteSArticle: 112937
> You can use picoblaze to program the SPI flash. I was looking for a quick solution. Since I don't have the same board as that app note and I have never worked with the picoblaze, this looks like a steep learning curve. I have been trying the Xilinx xspi_usb utility, but it has problems with the device id. If I tell it not to check the device id it fails on the bulk erase. If I use imPACT, Direct SPI Configuration, it also fails on device validation. Xilinx has been working on this problem for several days now, and they still don't have an answer for me. I could buy a module for the Advin programmer we have, but this seems a little excessive for programming one chip, one time. Is there a way to generate a HEX file that is compatible with the Avnet utility using iMPACT 8.2.03i? I spent a couple hours last weekend on my home computer, trying to get ISE 7.1 to work, but Corgen wouldn't work so I couldn't get my design to the point where I could follow the procedure in the Avnet documentation. The reason for purchasing the Avnet board is that it was much cheaper then doing my own board and I thought it would be much quicker. Usually we do our own boards and use the XC18V02 PROMS. What I need is a board with the Cypress USB Microcontroller and an FPGA. Looks like I have to spend the weekend building a programmer for the ST 25P40PV. Alternatively tell my boss I wasted the last month, fire up Mentor Graphics and do my own board. BillArticle: 112938
fl wrote:
> Hi, I still cannot get better performance, even for your code.
If I assign the same device, I also get your result.
I don't know how the author could do much better.
That's a real old part, by the way.
-- Mike Treseler
FLEX10K: EPF10K20RC240-4. 59.52 MHz ( period = 16.800 ns )
Info: Clock "clk" has Internal fmax of 59.52 MHz between source register
"\only:x_v[0]" and destination register "\only:sum_v[14]" (period= 16.8 ns)
Article: 112939"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:4tb8veF13bjqqU1@mid.individual.net... > glen herrmannsfeldt wrote: > >> I first heard about metastability in a discussion about the PDP-10 >> (KA10), which apparently had no metastability problem. The solution >> to metastability is asynchronous logic (also called self-timed logic). > > The D-flop is also an asynchronous circuit. > Mike, That's a much better reply than mine! Thanks. Cheers, Syms.Article: 112940
Hi Rob, I know that I have to use the assigment editor to change the output type from LVTTL (default) to LVDS. But when using LVTTL I always have access to the "output enable" of the output pin to tri- state the pin. But this does not work when using LVDS output. The output register is always enabled (OE set to '1') when I look at the design with the RTL viewer. This is a little bit strange because actually the Cyclone II parts do not have any "real" LVDS outputs. It is standard LVTTL and the LVDS voltage levels are generated by a specific set of resitors on the PCB. -- --------------------------------- --- -- - Posted with NewsLeecher v3.7 Final Web @ http://www.newsleecher.com/?usenet ------------------- ----- ---- -- -Article: 112941
I was wondering if anyone have experience running Aurora v2.4 on CES2 V4FX silicon? I am trying to debug a simplex channel between FX20 CES2 and FX60 CES4. The former uses Aurora v2.4 and the latter Aurora v2.5 (v2.5 doesn't support earlier silicon)... So far it doesn't work and I am not sure where to look... Part of the problem is that I couldn't successfully simulate simplex mode with Aurora v2.4, although it did work with v2.5. I haven't tried mixed core simulation (as I have in actual hardware), but I doubt it can work if v2.4 can't work (in simulation) by itself... Thanks, /MikhailArticle: 112942
PeteS wrote: > > Hi Gabor > > That's _very_ useful feedback. > > Thanks a lot! > > Cheers > > PeteS Here's another tidbit that cost me a couple hours today. Beware of the Global set/reset (under the hood) assignment. In ispLEVER, the tools will pick the most commonly used async reset in your design and use the global set/reset routing unless you specify otherwise. Then if you have something that isn't specifically reset some other way, it will be reset with this signal. This includes any instantiated flip-flops, like the ones you might use to create an internal synchonous-release reset inside the part (ala the Xilinx 4 FDP method). In this case you can have a loop that holds the part in reset forever. To prevent it you need to either tell the tools not to use the GSR routing resource, or specify for each module that shouldn't use it GSR = "DISABLED". In Verilog something like: // This flip-flop forms the internal reset, so it // can't be asynchoronously reset by the GSR // signal! FD1P3AX intrn_rst_ff ( .D (1'b1), .SP (1'b1), .CK (CPLD_REF_120), .Q (internal_resn) ) /*synthesis GSR="DISABLED"*/; Oh, yeah. Did I mention the wonderful library element names for flip-flop primitives? Good Luck, GaborArticle: 112943
Gabor wrote: > PeteS wrote: > >> Hi Gabor >> >> That's _very_ useful feedback. >> >> Thanks a lot! >> >> Cheers >> >> PeteS > > Here's another tidbit that cost me a couple hours today. > Beware of the Global set/reset (under the hood) assignment. > In ispLEVER, the tools will pick the most commonly used > async reset in your design and use the global set/reset > routing unless you specify otherwise. Then if you have > something that isn't specifically reset some other way, > it will be reset with this signal. > > This includes any instantiated flip-flops, like the ones > you might use to create an internal synchonous-release > reset inside the part (ala the Xilinx 4 FDP method). In > this case you can have a loop that holds the part in reset > forever. To prevent it you need to either tell the tools not > to use the GSR routing resource, or specify for each > module that shouldn't use it GSR = "DISABLED". In > Verilog something like: > > // This flip-flop forms the internal reset, so it > // can't be asynchoronously reset by the GSR > // signal! > FD1P3AX intrn_rst_ff > ( > .D (1'b1), > .SP (1'b1), > .CK (CPLD_REF_120), > .Q (internal_resn) > ) /*synthesis GSR="DISABLED"*/; > > Oh, yeah. Did I mention the wonderful library element > names for flip-flop primitives? > > Good Luck, > Gabor > I am using these comments (properly unattributed of course) to garner a complete set of free tools and competitive pricing ;) Seriously, I appreciate the comments; it is only by knowing what you guys have gone through that I can make a logical decision here. Cheers PeteSArticle: 112944
jez-smith@hotmail.co.uk wrote: > dh2006 schrieb: > >> I've read much about Double Buffering, especially that it is good >> practice (on Xilinx devices) to double buffer data signals (such as ADC >> inputs), and place the double buffer in the IOB associated with the >> pin. >> >> Can someone explain to me, what double buffering is and why you would >> use it? Any links to reference information would be appreciated. >> >> Many thanks. > Double buffering is one way of syncronising signals which are being > passed between clock domains, primarily in order to prevent problems > with metastability.Its not only xilinx devices in which this is used > its used in any situation where signals which are asyncronous to some > logic need to be syncronised.There are other methods which can be used > to achieve the same thing.A google search on metestabilty will give you > further information. ... and as an extra precision, "not only Xilinx devices" does not only mean Altera's, Cypress and other programmable logic companies. Double-registered async inputs are common fare in clocked digital circuits of any sort, ASICs are not somehow magically exempted from this.Article: 112945
Fair enough Ralf, I didn't mean to come crashing in so hard on your statement, so hope I didn't offend. I tend to prefer the term "blank canvas" for describing FPGAs to the uninitiated myself. It makes the whole process sound much more creative :-) Robin Ralf Hildebrandt wrote: > Robin Bruce schrieb: > > "A FPGA is nothing more than a prototyping platform" > > > > This an easily falsifiable statement. I've actually never knowlingly > > met anyone who has transferred an FPGA design to an ASIC. I'm not > > saying it doesn't happen a lot, just that there's obviously a whole > > community of FPGA users of whom you're not aware. > > Ok - I knew that this generalisation is like stepping into a nest of > hornets, but it is one of the shortest answers you can give to describe > what a FPGA is good for - especially if one does not know how much > knowledge has the OP. > > RalfArticle: 112946
Antti wrote: > John, > did you try reversing the ddr2 address bus bit endianess? > eg > A12>A0 > .. > A0>A12 > > if the sdram address bus endianswapped then same data appears > on multiply location, exactly as in your case I never understood why Xilinx did this. The JEDEC standard specifies fixed bit locations based on little endian ordering. Change to a different size SDRAM and the width of the bus changes, so in big-endian format, the location also changes. Seems like an unnecessary complication to the coding of the controller. As well as the confusion this has caused more than one of my engineers, and customers. I confess having participated in missing this detail before. I understand the big endian preference in the EDK. All the Coreconnect and PowerPC stuff from IBM is big endian. But I would suggest it should really only be a preference, and not an absolute. Having both read and written a lot of code, mixed endian is much easier to follow when the endianness of any given bus/endpoint follows the source documentation (i.e. the JEDEC standard, or the component data sheet, rather than the IP). Not to mention the fact that we name our PCB nets based on the physical design (i.e. DRAM pin names, rather than SDRAM IP names). Rant mode off. We saw an instance some years ago with the Xilinx tools where an endian reversal happened at a port. Now it has been some time, so I don;t remember the exact details. It may have been a platform studio problem, but I seem to recall it being farther down stream, XST or even the mapper. THe design used both Verilog and VHDL modules. The only workaround that we could find was to keep the endianness of the IP through EDK to the UCF file, all the way out to the FPGA pins, and do the swap (in effect) outside the FPGA. Before dismissing this as unsubstantiated urban legend (which I would do with anything so hazy as the recollection I am offering), I would suggest using FPGA editor to trace back one address signal back through the FPGA to prove that an endian swap did not happen in the tools. We were overworked and overtired at the time, so it is possible I never filed a case with Xilinx on this. My suggestion is of course unneccessary if Antti's suggestion helped you find the answer. I second his notion, as this behavior is exactly as we saw when we had a backwards address bus on a DDR SDRAM. Would be nice to know how you resolve the problem, as we have our first DDR2 board coming back in a week, and any additional information might help me avoid the same problems. We will be using a single 512Mb DDR2 in a x16 configuration. We will have to do our own controller for this eventually, but we plan to get "hello world" working with a stock controller. We have size and speed reasons to do our own controller: our IP and the PowerPC processor only do single 64bit byte enabled, or quad-doubleword read/writes; and we have no need for all of the extra fancy stuff that is included with the Xilinx cores. I also seem to recall that there is no Xilinx IP to direct attach a x16 DDR2 to a 64bit PLB bus at a bit rate 4x the PLB. Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 (fax) 617.695.9234 (web) http://www.birger.comArticle: 112947
Hi I am using modelsim for simulation and quartus 6.0 for remaining.I have generated custom netlist ffrom quartus.I want to simulate in modelsim .How to link library of cyclone device.How to do that.Can anybody help me.Thanking youArticle: 112948
Why do you want to tri-state the LVDS outputs? "tentacle" <onlyspam@online.ms> wrote in message news:3ebd3$45708bb0$54964b97$1398@nf16.news-service.com... > Hi Rob, > > I know that I have to use the assigment editor to change the output type > from LVTTL > (default) to LVDS. > > But when using LVTTL I always have access to the "output enable" of the > output pin to tri- > state the pin. But this does not work when using LVDS output. > > The output register is always enabled (OE set to '1') when I look at the > design with the > RTL viewer. > > This is a little bit strange because actually the Cyclone II parts do not > have any "real" > LVDS outputs. It is standard LVTTL and the LVDS voltage levels are > generated by a specific > set of resitors on the PCB. > > > -- > --------------------------------- --- -- - > Posted with NewsLeecher v3.7 Final > Web @ http://www.newsleecher.com/?usenet > ------------------- ----- ---- -- - >Article: 112949
Erik Widding schrieb: > Antti wrote: > > John, > > did you try reversing the ddr2 address bus bit endianess? > > eg > > A12>A0 > > .. > > A0>A12 > > > > if the sdram address bus endianswapped then same data appears > > on multiply location, exactly as in your case > > I never understood why Xilinx did this. The JEDEC standard specifies [snip] Hi Eric, the endian swap was(is) usually done in the UCF file. no one understands why it has to be so (from those I have explained it to) but that it is mostly, it however isnt always necessary, in MPMC2 docs it says that take the non MPMC2 design, then replace the DDR2 core and __undo__ the endianswap, well I did undo and it did not work, but well I possible did partial fix, so maybe the UCF undo _and_ MHS toplevel port swap would have worked also. so or so I think I got the endian swap correct, but here is the report first I have a board (actually more than one, several different boards) with only one 16bit Micron DDR2 chip fitted. The board works well with MIG and with OPB_MCH_DDR2 PLB_DDR2 is faster than OPB_MCH_DDR2, but I think it is not supporting 16bit memory, and it is not multichannel core, so essentially i need a DDR2 that is both multichannel and high performance (the max 50MByte/sec in burst accesses with OPB_MCH_DDR2 is just a joke), so the obvious solution is MPMC2 attempt 1: MPMC2, 1 port, OPB does not work at all (read stall) because the datapath fifo doesnt support 32 bit wide mode. attempt 2: MPMC2, 1 port PLB does not work at all because the datapath read fifo writes to the fifo at wrong time, as shown in simulation it happens 2 clocks after the data from DDR2 is valid at the fifo input in the FPGA the same design does readback 1 32 bit word correctly, but I also was seeing that reads are latched at wrong time, eg as if the core would lath DDR2 data 1 clock too late, eg data written to offset_base8+4 appears at offset_base8+0 (correct data), and one half of the 32 bits appears duplicated in both halfs of the word read back from offset_base8+4 I have a DSO on the DQS and DQ, and I can see that the DDR2 memory returns valid data, sot the DDR2 core should be able to fethch it, but it happens really at wrong time slots. It really seems that ****ONLY**** those configurations that are present in the MPMC2 ref design directory only work, and that ****EVERY**** other configuration will most likely fail. as of the generic _wrong_endian_ and endian fix in UCF thing, I personally have wasted (accumulated over many years) at least one man-month of active development time. My estimate is that the time wasted by all Xilinx customers over this issue is way more than 10 Man-Years of time wasted. Considering this it is really ridiculous that Xilinx even charges money for this, in the matter of fact Xilinx should pay to all EDK users in advance to compensate the time wasted by the customers. Antti
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