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
Ah, microprocessors, the "gateway" technology. Start using those and pretty soon you'll be into stronger stuff like FPGAs. Peter Alfke wrote: > So were microprocessors and PCs in an earlier era, and amateur (ham) > radio even earlier... > Peter Alfke, >> So, to tie in with another part of this thread, FPGA's really are like >> drugs. Get them while they're young and the first hit is free. >> >> Alan Nishioka >> a...@nishioka.com > >Article: 120176
That would be 360 pins for LVDS and 1280 pins for the FIFO (read and write). That's a lot. BTW: Price for FPGAs grows faster than linear with size. You are probably better of with multiple small chips. Also, the PCB should be easier to route if you have less FIFO chips per FPGA. Kolja Sulimma On 2 Jun., 14:30, Test01 <cpan...@yahoo.com> wrote: > Thanks for your feedback. I will utilize the recommended tool and the application note in my application. > > I do have a couple of questions: > > (1) With internal 1 to 4 deserializer as recommended, the internal data bus will be 640 bits wide at 200 MHz. I would like to buffer this externally using deep FIFO. If the FPGA has enough number of pins, is it OK to also include the 640 bits wide, 200MHz external FIFO in the same FPGA as the 180 differential input, 800Mbps interface? I was thinking about using Virtex5 110 device for this application. It will be great to get your feedback. (2) For similarly configured differential outputs from another FPGA (I call it transmitter FPGA) are there any concerns of simultaneous switch noise? 180 differntial outputs switching simultaneouly at 800Mbps. As per my understanding, the simultaneous switching noise applies more to the single ended outputs and not as much to the differential output. The common mode noise on differential noise (ss noise) will be there but it will be subtracted by the receiver. Is that correct?Article: 120177
I was thinking that to unload the fifo, I will use separate FPGA as that is not on the critical path. For the receiver FPGA, the write to the FIFO is most critical. Thus ideally, I would like to have the receiver FPGA contain 180 diff inputs(800Mbps each) and 640+FIFO Control outptuts(200Mbps each). As per my understanding biggest virtex5 fpga contains about 1200 user i/o What are the issues that you all see with this approach?Article: 120178
Pasacco wrote: > Hi > > I have problem to implement a FIFO with "Synchronous WRITE, > Asynchronous READ" in Xilinx device. > > Since the FIFO size is large (more than 48-deep words), I would like > to use BRAM or Built-in FIFO. > > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM > and it seems okay. > > Problem is that > > Every time we 'read', one cycle delay occurs. > I want to 'immediately read' a data in the location that the "read > address" points to. > > I am not finding a way to implement "Asynchronous READ" in BRAM. > > If anyone has this experience, please let us know. > Thank you in advance It's a FIFO, not a random read so your life is simpler. The question is whether you need first-word fall-through or not. Peter Alfke is, of course, the expert on the ins and outs of FIFOs but I'll make a quick suggestion to address your troubles. For simpler methods to reach your goals, please specify the family of device you're using. It's also not obvious that the clock is the same on both sides of the FIFO. For the moment I'm assuming it is. You MUST indicate if it's different domains. One approach is to build your own FIFO controller. Synchronous FIFOs are pretty simple: you have a read pointer, a write pointer, some full and empty logic per your tastes, and controls to keep the FIFO from an overrun or underrun condition. The total design is about 5 lines of active code in RTL (ignoring all the reset states and structure for this discussion). To get the first word there the moment your read pulse is active, you need to "prefetch" the first value. With a write pointer that puts its first word into BRAM location 0, the read has to be pointing to BRAM location 0 *before* the read pulse and the BlockRAM must be enabled to get that first location out. You have - without using a read pulse - the first word present on your FIFO output. When the read pulse indicates you're taking that word, you advance to the next value and "preload" that into your BlockRAM output for your next read pulse. If you have two consecutive reads, the combinatorial read address increase that you must code will load the next read value on the next clock. If the value isn't written yet for that new value, the empty must be asserted until the write value propagates the value to the read port. You can affect this same behavior with a wrapper on your existing FIFO as well. The empty flag, external read and internal read need to be coordinated to perform a preload of your desired "asynchronous" value to the output. It's not that tough if you look at the logic as a preload. Is you system so messed up that you need the old value to be present until the read pulse is active for the new value? Still not a problem! The preloaded output would work with an external register for the previously read value and the preload value. When the read pulse is not active, the register is selected. When the read pulse *is* active, the BRAM value is selected and the hold register updates at the upcoming clock edge. FIFOs with clocks on both the input and output domains are some of the simplest control mechanisms you can deal with. If you actually need two different clock domains for your input and output sides, life is less simple but the external wrapper logic I suggested earlier will easily provide you with asynchronous access to your next word from a standard synchronous-output FIFO when your read pulse asserts. Think more about how your design needs depart from the FIFO structures available to you and consider how you can change the FIFO or change your system to make everything happy. The conversion should be reasonably clean if you look at it from the proper perspective. But if you want more of a turnkey solution, go into more detail on the specifics. Family. Fall-through. Clock domains. - John_HArticle: 120179
Test01, I would study the networking cores in the IP library. They require one clock forwarded, for every N data lines, where N gets smaller as the speed goes up. I think that for 180 paths, you may need as many as 10 clocks (each 18 bits get a clock). That makes 190 LVDS pairs, and 10 BUFG global clocks. Banking will be an issue, as in V5 I think we have banks of 20, and banks of 40 (pins, IO's, and LVDS takes two pins), so the bank of 20 is too small one set of 18 signals + clock, and a bank of 40 is one set of 18 signals + clock. That makes for 10 banks of 40 IO's, so you need to size the part to match. I would not do this from scratch, but follow a networking core (e.g. SPI POS 4.X). PCB layout will be a real challenge, as you will need to make all traces the same length (including the traces in the package to the die). There are advanced interfaces that will automatically adjust all the delays to get the bits all centered (pcb traces can be anything you like), but I don't think you can fit that many of these cores in one chip (you run out of something, like DCM's, or serial IO resources). Local clocks only go to 200 MHz, so they can be used with the per pin serializer/deserializer. Each clock gets 4 bits in time. Again, this is a real challenge, and puts you in the rarefied world of extremely high speed design. The pcb after layout has to be extraced, and run in an SI tool, or else you are pretty much doomed to fail. Only after you prove that all signals get from here to there, and all the SI is acceptable, and simulate an eye pattern on each and every of the 180 lines, and 10 clocks, are your ready to fab the pcb. AustinArticle: 120180
In article <1180769858.872726.132740@i13g2000prf.googlegroups.com>, Totally_Lost <air_bits@yahoo.com> wrote: >I've been looking at the various core/macro generators and they all >seem horribly large and slow, almost like student designs. Has anyone >seriously taken a good look at hand fitting multipliers and squarers >into Altera/Xilinx FPGA's? I believe Dan Bernstein has, in the context of fast factorisation machines, but I don't think he's published yet. http://cr.yp.to/djb.html is his rather disorganised Web page. TomArticle: 120181
Austin, Thanks for your input on this one as I am bit puzzled on where to start. I was looking at xapp705 to use iserdes and oserdes and build upon that. It seems that you have something even better - SPI/Networking application. I will look into that as well. When I said 180 diff pairs at 800Mbps, I meant 160 diff pairs for the data bus and 20 diff pairs for 400MHz DDR clock. Thus the sum total will be 180 diff pairs into the FPGA. There will a clock for every eight bits. The FPGA will use 1 to 4 deserializer to further widen the data bus to 640 bits at 200MHz. I could use internal fifo inside the fpga to store the 640 bits wide data but ideally I would like to store it in the external fifo due to the size advantage. The receiver fpga containing the 180 diff paris and 640 bits, 200Mbps output to the fifos will be involved in writing to the fifo and reading can be done by some other fpga. Please let me know your thoughts on the external Fifo interface.Article: 120182
"morphiend" <morphiend@gmail.com> wrote in message news:1180789416.354586.306120@m36g2000hse.googlegroups.com... > > Is it possible that the CDMAC is doing some operation on > the data and accidentally corrupting it? Are your memory buffers properly aligned? The boundary they have to be aligned to depends on the write/read mode used, but I believe it is safe to align them to 128 byte boundary. /MikhailArticle: 120183
On Jun 2, 10:27 am, Jan Pech <n...@spam.please> wrote: > On Sat, 2007-06-02 at 13:08 +0000, morphiend wrote: > > I have a system on a Virtex4-FX with a MicroBlaze and the xilinx > > opb_emc (v 2.00). I thought I set up the parameters properly to match > > the async FLASH memory chip that I have on my development board, but > > the controller does not look to be respecting the settings I set. > > > I have the system running at 100MHz, and the external FLASH chip is a > > 70ns Spansion part. On a read, the address needs to stay valid for > > 70ns, but it's only staying valid for ~2 cycles (where the cycles are > > based upon the 100MHz clock, and observed using ChipScope). The same > > happens for a write, for say putting the chip into CFI mode, the write > > line is only staying asserted for ~2 cycles when it needs to be 70ns > > as well. > > > I tried increasing the timespec values for the ipcore, but the > > external operation stayed exactly the same even if I doubled the > > requirements. > > > Has anyone seen or experienced similar problems? > > > TIA, > > > Mike Koss > > Mike, > Did you set the memory type to asynchronous? What you describe looks > like synchronous mode. > Jan Yes I have it currently set to asynchronous, because the part I was interfacing to is asynchronous (no clock input). Is this not the correct assumption?Article: 120184
I use RAMB16_S36_S36 primitive (for the moment) and "common single clock". Prefetching is very interesting, though it is hard to understand for the moment :). Thank you for info.Article: 120185
Pasacco wrote: > Hi > > I have problem to implement a FIFO with "Synchronous WRITE, > Asynchronous READ" in Xilinx device. > > Since the FIFO size is large (more than 48-deep words), I would like > to use BRAM or Built-in FIFO. > > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM > and it seems okay. > > Problem is that > > Every time we 'read', one cycle delay occurs. > I want to 'immediately read' a data in the location that the "read > address" points to. > > I am not finding a way to implement "Asynchronous READ" in BRAM. > > If anyone has this experience, please let us know. > Thank you in advance > The BRAMs are synchronous devices; you cannot read them asynchronously. So the only solution is some sort of prefetching, as mentioned. The CLB RAMs do allow asynchronous reads, and "more than 48-deep words" is not terribly large. That means probably 4 CLBs per word bit (depending on the device used), so a 16 bit word is 64 CLBs. Not really that many. So you might want to consider just using them if you don't want to bother with prefetching.Article: 120186
On Jun 2, 4:37 am, Marlboro <cco...@netscape.net> wrote: > On Jun 2, 12:26 am, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > On Jun 1, 6:38 pm, Marlboro <cco...@netscape.net> wrote: > > > > A memory block has been told having "read latency of 3", assume the > > > read pointer has been reset > > > > How many read clocks does it take to read out the first 10 bytes? > > > As many as it has too, gosh!! > > Lol, I meant the min. number of clock cycle it takes to read out the > first 10 bytes 83 obviously. Is this your homework assignment? You should have noticed that there are key details missing in the question. TommyArticle: 120187
Test01, If it were me, I would figure out how to do everything inside the FPGA. Moving the data out to a FIFO, and back in again, you still have all those data running at 800 Mbs per pair. FPGA fabric is the perfect place to expand to a huge wide bus, go into the 36K BRAMs (used as FIFO's, or used with read/write pointers on their dual ports). What are you going to do with all this data once you have received it, and placed it in a FIFO? Obviously, there is some kind of "output" from this design, what is it? If the amount of storage on the FPGA is insufficient, then yesy you will have to put it somewhere else. A natural for this is DDR SDRAM. You may build the FIFO functionality from any memory: use the fastest and least expensive memory you can. AustinArticle: 120188
Try without Xilinx driver ;) http://www.rmdir.de/~michael/xilinx/Article: 120189
On Jun 1, 10:30 am, linnix <m...@linnix.info-for.us> wrote: > On Jun 1, 10:12 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 1 Jun., 17:53, linnix <m...@linnix.info-for.us> wrote: > > > > On Jun 1, 7:34 am, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > > On May 31, 11:36 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > On 1 Jun., 07:41, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > > > > On May 31, 4:42 pm, ghel...@lycos.com wrote: > > > > > > > > On May 31, 3:43 pm, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > > > > > > Anyone know how the USB Blaster cable loads data to the C3 fpga on the > > > > > > > > board? The schematic shows a CPLD between the FPGA and the USB port. > > > > > > > > There is a USB to parallel chip between the cpld and the usb port. > > > > > > > > But I do not see any serial or parallel data going to the fpga. > > > > > > > > > I wish Altera added more details to the starter kit documentation. > > > > > > > > There is all this source code but it is encrypted. So cannot even > > > > > > > > look at that. > > > > > > > > > TIA > > > > > > > > -sanjay > > > > > > > > That CPLD along with the FT245 is the "embedded USB Blaster". You > > > > > > > won't see any lines to the FPGA except for the JTAG leads. (I found > > > > > > > the JTAG lines on the schematic - look again.) > > > > > > > > The documentation looked pretty complete to me. For the Xilinx board, > > > > > > > the page of schematic with the USB loader is *missing*, and that area > > > > > > > of the layout is obscured. > > > > > > > > Both companies used to ship separate dongles with their eval boards. > > > > > > > But the plastic case of the dongle is the most expensive part, > > > > > > > followed by the JTAG leads. By leaving those out, they can add the > > > > > > > USB programmer for almost nothing. > > > > > > > > It's possible that both companies contracted out the design of their > > > > > > > USB programming pods, so they can't (legally) distribute the > > > > > > > information on the device. (Both companies make a ton of money > > > > > > > selling IP; you have to understand that they will respect the IP > > > > > > > rights of others.) > > > > > > > > Do a web search. There are a number of people actively tring to > > > > > > > reverse engineer both dongles. At least until they discover hat > > > > > > > they're spending 100's of hours to duplicate a gizmo that can be had > > > > > > > for $50... > > > > > > > > G. > > > > > > > Sorry I wasn't clear. By data I did not mean the configuration or > > > > > > jtag stream. Not sure if you are familiar with the C3 starter board. > > > > > > But they have something called control panel, which you use to test > > > > > > the dram access besides other things. You can read and write to the > > > > > > sdram. Store entire files, etc. And the only host interface I see > > > > > > for this is the usb interface. But I do not see any data lines. So > > > > > > that is what I mean by data. > > > > > > > Please let me know where to look if you find that in their > > > > > > documentation. > > > > > > > Thanks. > > > > > > Best, > > > > > > -sanjay- Zitierten Text ausblenden - > > > > > > > - Zitierten Text anzeigen - > > > > > > well, there is no need for more then JTAG lines ;) > > > > > Altera FPGAs can have user logic in fabric connected to the JTAG TAP, > > > > > so the same JTAG pins can be used to talk to the user app as well. > > > > > this is how signaltap works as example > > > > Jtag can scan all boundary cells (most I/O pins) and using them to > > > drive external devices as well. > > > > > > Antti > > > > > Thanks Antii. I had suspected this. And I think this is a cool > > > > feature for low bandwidth operations such as serial communication. > > > > As long as the serial pins are in the boundary scan chain, which is > > > usually the case. However, sometimes the internal buffers get in the > > > way of boundary scans. > > > > > I am thinking how can I use this in my application? > > > > Build (or buy) your jtag scan engine, like many of us do. > > > > > Please let me know > > > > if you have any pointers. > > > > > TIA. > > > > -sanjay- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen -- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > hm, > > when you use the "JTAG in FPGA fabric" approuch then JTAG boundary > > scan chain is NOT USED. > > There are certainly many ways to configurate the FPGA. For > development and temperatory configuration, you can jtag into the FPGA > directly. However, real app configuration is usually stored in > external flash chip. A typical jtag tool would program the external > flash chip via boundary scan. I think the question is how to use the jtag port to read and write to the configured logic inside the fpga. This is different from configuring the fpgas. I did find the answer. Altera has virtual jtag interface (sld_virtual_jtag). Thanks for the discussion. Best, -sanjayArticle: 120190
If you use a BlockRAM as a FIFO, you have to accept that any read operation is synchronous, i.e. the result of a read-clock edge. First-word-fall-through puts the first word written into a previously empty FIFO onto the output, synchronously with the read clock, but irrespective of the read clock enable. I call it a push operation, as opposed to the pull in normal mode. Once more than one word is in the FIFO, there is no difference between the two modes, you can always get a new word on the nect Read clock tick, if that is what you want. Peter Alfke, Xilinx On Jun 2, 11:18 am, Duane Clark <junkm...@junkmail.com> wrote: > Pasacco wrote: > > Hi > > > I have problem to implement a FIFO with "Synchronous WRITE, > > Asynchronous READ" in Xilinx device. > > > Since the FIFO size is large (more than 48-deep words), I would like > > to use BRAM or Built-in FIFO. > > > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM > > and it seems okay. > > > Problem is that > > > Every time we 'read', one cycle delay occurs. > > I want to 'immediately read' a data in the location that the "read > > address" points to. > > > I am not finding a way to implement "Asynchronous READ" in BRAM. > > > If anyone has this experience, please let us know. > > Thank you in advance > > The BRAMs are synchronous devices; you cannot read them asynchronously. > So the only solution is some sort of prefetching, as mentioned. The CLB > RAMs do allow asynchronous reads, and "more than 48-deep words" is not > terribly large. That means probably 4 CLBs per word bit (depending on > the device used), so a 16 bit word is 64 CLBs. Not really that many. So > you might want to consider just using them if you don't want to bother > with prefetching.Article: 120191
Austin, Once I capture the data into the external memory, I will retrieve the data using some back-door communication to the memory. My preference was to keep the external memory interface as simple as possible as this is the first time I am attempting complexity on the 800Mbps interface. Ultimately 160 data channels 800 Mbps each funnels down to 20 channels at 6.4 Gbps each. This interface is a bit more complex so we wanted to minimize the complexity on the memory side. DDR interface has some overhead associated with it and will need more then one DDR interface to keep up with the data rate. This is why I liked the FIFO solution. But is it feasible to have 180 diff paris 800Mbps and 640+ singled ended i/os 200Mbps each in one FPGA? Inside the FPGA fabric there is not much going on. I am not sure if V5 LX110 can meet the I/O and internal logic requirements? Thanks for your input.Article: 120192
Test01, You did not answer my question. Where are the 20 6.4 Gbs transceivers? How do get to them? Are you assuming that these 20 6.4 Gbs transceivers are already inside the FPGA? Why leave the FPGA, only to come back into the FPGA? 640 X 200E6 = 128 Gbs, and 20 X 6.4 = 128 Gbs, but that implies that you have no encoding, or overhead, which is not practical. Where do you find 6.4 Gbs transceivers? I suspect you need 8B10B coding, or at least 64/66B coding, which then bumps you up to 8 Gbbs, or 6.5 Gbs, respectively. You will need channel bonding to concatenate 30 MGT channels together, and some kind of protocol (Aurora core is free). I still don't know why you are doing any of this...fun? video? data? radio? Is it a state secret? Asking: "can the V5 do XXX" is of no use to anyone. If you wish to have a system architected by a committee, and designed by rumor, opinion, and hearsay, then I have to hit the "ignore" as this project will never succeed, and provide any revenue to Xilinx (it is, a complete waste of my time). I am sure whatever it is, can be done by proper use of FPGA technology. How you are going about it is very odd. You seem to be architecting your system around a bunch of LVDS pairs, why? Perhaps, it would be best if you contracted with one of the Xilinx expert consultants out there, or perhaps with Xilinx design services? What you are asking is non-trivial, and is very difficult, even when done correctly, by experts. 800 Mbs LVDS with as many wires as you need is a lot of work to get done right (as I have previously described). Sorry, I have lost interest in this, as you are not answering my direct questions (what are you doing? why?). Sorry, <ignore thread> is now ON. AustinArticle: 120193
Mike, BTW, did you write the adapter layer LL_TEMAC driver for linux yourself? Thanks, /MikhailArticle: 120194
On Jun 2, 1:21 pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > On Jun 2, 4:37 am, Marlboro <cco...@netscape.net> wrote: > > > On Jun 2, 12:26 am, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > On Jun 1, 6:38 pm, Marlboro <cco...@netscape.net> wrote: > > > > > A memory block has been told having "read latency of 3", assume the > > > > read pointer has been reset > > > > > How many read clocks does it take to read out the first 10 bytes? > > > > As many as it has too, gosh!! > > > Lol, I meant the min. number of clock cycle it takes to read out the > > first 10 bytes > > 83 obviously. > > Is this your homework assignment? Nope > You should have noticed that there > are key details missing in the question. > Maybe so maybe no. Let look at these scenarios For a normal person we may ask: How muck does it cost to travel by taxi from Milano to Roma? But for someone like you we need to ask What's the min. taxi fare to go from Milano to Roma? By the way, how do you know the memory data width = 1? :))Article: 120195
Austin, The short answer is, I am not using the MGT or GTP to achieve 6.4 Gbps per channel. There are external discrete components to achieve this. We are going to have training algorithm to achieve bit alignment and packet alignment. It did not seem relavant to my original question so I did not mention it. Also the very high speed (6.4 Gbps) is not something that I am dealing with myself and it is some one else is looking at. I hope this answered your question.Article: 120196
On Jun 2, 6:45 pm, "MM" <m...@yahoo.com> wrote: > Mike, > > BTW, did you write the adapter layer LL_TEMAC driver for linux yourself? > > Thanks, > /Mikhail Yes and no. It was modified from the MontaVista 2.4 GEMAC adapter. I bridged that with the MV 2.6 TEMAC driver to get a driver together. The 2.4 GEMAC driver was previously using the CDMAC.Article: 120197
Dear all,
i am trying to implement a memory controller and am getting the
following errors during translate.
i wud greatly appreciate if u cud provide some comments/suggestions.
thanks,.
Mahalingam
Process "Synthesize" completed successfully
Started : "Translate".
Command Line: ngdbuild -intstyle ise -dd _ngo -nt timestamp -uc
mem_interface_top.ucf -p xc2vp30-ff896-7 testbench.ngc testbench.ngd
Reading NGO file 'C:/Xilinx/memory_interface_koustav/
testbench.ngc' ...
Applying constraints in "mem_interface_top.ucf" to the design...
Checking timing specifications ...
Checking expanded design ...
WARNING:NgdBuild:440 - FF primitive
'mymeminttop/ddr1_top0/controller0/ACK_REG_INST1' has unconnected
output pin
ERROR:NgdBuild:924 - input pad net 'myclk' is driving non-buffer
primitives:
pin C on block my_user_command_register_1 with type FDE,
pin C on block my_user_command_register_2 with type FDE,
pin C on block my_led_error_output with type FDE,
pin C on block tmp_user_config_register_1 with type FDE,
pin C on block init_count2_0 with type FDE,
pin C on block init_count2_1 with type FDE,
pin C on block init_count2_2 with type FDE,
pin C on block init_count2_13 with type FDE,
pin C on block init_count2_14 with type FDE,
pin C on block init_count2_15 with type FDE
WARNING:NgdBuild:483 - Attribute "IOSTANDARD" on "led_error_output" is
on the
wrong type of object. Please see the Constraints Guide for more
information
on this attribute.
WARNING:NgdBuild:483 - Attribute "LOC" on "led_error_output" is on the
wrong
type of object. Please see the Constraints Guide for more
information on
this attribute.
ERROR:NgdBuild:455 - logical net 'myclknot' has multiple driver(s):
pin O on block myclknot1_INV_0 with type INV,
pin PAD on block myclknot with type PAD
ERROR:NgdBuild:925 - input net 'myclknot' is connected to the
incorrect side of
buffer(s):
pin O on block myclknot1_INV_0 with type INV
NGDBUILD Design Results Summary:
Number of errors: 3
Number of warnings: 3
One or more errors were found during NGDBUILD. No NGD file will be
written.
Writing NGDBUILD log file "testbench.bld"...
Process "Translate" failed
Article: 120198I would like to add to my previous reply. I applogize if I did not answer your direct question. It is quite possible that I did not understand the question. FPGA is just one of the component of the project that I am responsible for and I hav some understanding of its limitations but not full. Again I am sorry if I did not answer the questions directly.Article: 120199
On Sat, 2007-06-02 at 17:40 +0000, morphiend wrote: > On Jun 2, 10:27 am, Jan Pech <n...@spam.please> wrote: > > On Sat, 2007-06-02 at 13:08 +0000, morphiend wrote: > > > I have a system on a Virtex4-FX with a MicroBlaze and the xilinx > > > opb_emc (v 2.00). I thought I set up the parameters properly to match > > > the async FLASH memory chip that I have on my development board, but > > > the controller does not look to be respecting the settings I set. > > > > > I have the system running at 100MHz, and the external FLASH chip is a > > > 70ns Spansion part. On a read, the address needs to stay valid for > > > 70ns, but it's only staying valid for ~2 cycles (where the cycles are > > > based upon the 100MHz clock, and observed using ChipScope). The same > > > happens for a write, for say putting the chip into CFI mode, the write > > > line is only staying asserted for ~2 cycles when it needs to be 70ns > > > as well. > > > > > I tried increasing the timespec values for the ipcore, but the > > > external operation stayed exactly the same even if I doubled the > > > requirements. > > > > > Has anyone seen or experienced similar problems? > > > > > TIA, > > > > > Mike Koss > > > > Mike, > > Did you set the memory type to asynchronous? What you describe looks > > like synchronous mode. > > Jan > > Yes I have it currently set to asynchronous, because the part I was > interfacing to is asynchronous (no clock input). Is this not the > correct assumption? > Your assumption is correct. But from the behavior you described I got the feeling the mode had been set to synchronous. When you choose asynchronous mode of the EMC, the controller takes into account the timing parameters. If you set the synchronous mode, the only timing related parameter EMC looks at is the pipeline latency (1 or 2 clock cycles). At least OPB_EMC v. 2.00.a behaves this way. Jan
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