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
"Philip Pemberton" <usenet09@philpem.me.uk> wrote in message news:00b7c995$0$4795$c3e8da3@news.astraweb.com... > Signetics were definitely before MMI. Yes. I remember marking up fuse maps by hand, then sending them away to Signetics and waiting for a couple of days to get the parts back. After a few weeks we got an upgrade to our programmer that allowed us to program without trashing too many parts (as long as we blasted them with freeze spray during programming). PeteArticle: 142226
Mike Treseler wrote: > Griffin wrote: > > I am trying to build an FPGA based system where I have an input from > > the outside world in the form of a logic level. Ever clock cycle, I > > check what the input logic level is and then if it's high I increment > > a counter. The value of this counter is then stored into the board's > > onboard DDR SDRAM. The values in this DDR must then be read out to a > > computer. > > If it's just one counter, I don't need any ram. > The other logic is very simple. It's actually 7 24-bit counters to worry about. My sampling rate is on the order of a few every microsecond, which I'm pretty sure will require the ram to function as a buffer. > > I figured that the best way to read out these values to the computer > > would be some sort of web server that interfaces with the onboard DDR > > somehow, which is more or less where I get lost. > > I would start with a parallel or serial port interface > to the PC. I suppose this would be a good place to start. I had wanted to implement a web server under the suggestion of a professor here, but it's not necessary. > > > I'm not entirely sure how to make the jump from writing VHDL scripts > > and loading them into the FPGA to embedded processes which execute the > > VHDL code. > > Your vhdl code is converted to a netlist of gates and flops by > synthesis. VHDL code is only executed on a simulator. > > > So in a nutshell I'm not sure how to: > > 1- Have an embedded processor execute VHDL scripts. > > An embedded processor executes machine code > from a C complier or an assembler. > If I have an external computer reading the register, > I don't need a cpu core on the fpga anyway. > > VHDL code might *describe* a cpu, but it does not run on one. > > =A0 =A0-- Mike Treseler Thanks for the response!Article: 142227
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>http://i.cmpnet.com/eetimes/news/09/07/1565chart_pg18.gif
>
I remember the Motorola fpgas. Free software (from Pilkington). I've
never seen the actual devices though...
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142228Griffin wrote: > It's actually 7 24-bit counters to worry about. My sampling rate is on > the order of a few every microsecond, which I'm pretty sure will > require the ram to function as a buffer. 7 24-bit counters would easily fit in registers in many FPGAs (e.g. std_logic_vector signals in VHDL). You don't need any RAM at all, even no internal block RAM. This makes the implementation much easier than using external DDR SDRAM, if you are using VHDL and not some embedded system, like NIOS or MicroBlaze. >>> So in a nutshell I'm not sure how to: >>> 1- Have an embedded processor execute VHDL scripts. I assume you are using some synthesized CPU? In NIOS it is possible to include your own VHDL entities. They are compiled together with the rest of the system to a netlist, which then can be loaded into the FPGA. This would make your task very simple, but maybe a good idea to start with. The most complicated thing would be to fiddle around with the sometimes not very intuitve tools for creating the embedded system configuration. The VHDL entity for counting is very simple, the rest would be C. Some embedded system configuration tools allow you to just add TCP/IP support and provides the C libraries, so your C program would be something like 100 lines standard C for a simple web server, which can display the counter values. I assume nearly all embedded system tools provide RS232 support, which would reduce your C code to something like 10 lines. Of course, would be much more fun to implement your own RS232 entity and protocol, all in pure VHDL :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142229
On Jul 28, 9:30 pm, Nicholas Kinar <n.ki...@usask.ca> wrote: > It seems that most designers are strongly polarized with respect to > which programmable logic company should be used for designs. Altera, > Xilinx and Lattice are supposedly the "Big Three" companies. > > For example, JVC uses Xilinx in professional video products: > > http://www.xilinx.com/prs_rls/design_win/06123jvc.htm > > Alternately, Panasonic uses Altera: > > http://www.altera.com/corporate/news_room/releases/2009/products/nr-p... > > I would wonder which is better to use for designs, and if the history of > design has a role to play in selection. Note that the chart shows > that most programmable logic companies started up around the same time. The real issue for most companies that use significant quantities of product is cost. To that end, you always have to keep the vendor honest by having an alternative to their parts. I know for a fact that if they want your business, they will cut prices to the bone leaving you all the fat. So you have to be able to switch vendors without significant impact on your design implementation. Even if they won't switch for a given product, they have to be able to use the part that has the lowest cost. One place I worked knew this very well and every new socket was competed on price before the board was designed. Of course this does not apply if your design requires some feature that is not available in a competitor's part, such as a particular high speed serial I/O capability. Some vendors will tell you that this is not a smart way to go since you can't take advantage of "special" features of each part. I have yet to find an application where using a "special" feature will change the implementation so much that it will allow me to use a cheaper part from a different vendor. I'm sure that can happen, but I don't expect it to happen a lot. So for most cost sensitive apps, a company will do better to compete the FPGA vendors against each other or you will be giving them the fat on your designs. RickArticle: 142230
On Jul 29, 2:17 pm, Griffin <captain.grif...@gmail.com> wrote: > Mike Treseler wrote: > > Griffin wrote: > > > I am trying to build an FPGA based system where I have an input from > > > the outside world in the form of a logic level. Ever clock cycle, I > > > check what the input logic level is and then if it's high I increment > > > a counter. The value of this counter is then stored into the board's > > > onboard DDR SDRAM. The values in this DDR must then be read out to a > > > computer. > > > If it's just one counter, I don't need any ram. > > The other logic is very simple. > > It's actually 7 24-bit counters to worry about. My sampling rate is on > the order of a few every microsecond, which I'm pretty sure will > require the ram to function as a buffer. > > > > I figured that the best way to read out these values to the computer > > > would be some sort of web server that interfaces with the onboard DDR > > > somehow, which is more or less where I get lost. > > > I would start with a parallel or serial port interface > > to the PC. > > I suppose this would be a good place to start. I had wanted to > implement a web server under the suggestion of a professor here, but > it's not necessary. > > > > > I'm not entirely sure how to make the jump from writing VHDL scripts > > > and loading them into the FPGA to embedded processes which execute the > > > VHDL code. > > > Your vhdl code is converted to a netlist of gates and flops by > > synthesis. VHDL code is only executed on a simulator. > > > > So in a nutshell I'm not sure how to: > > > 1- Have an embedded processor execute VHDL scripts. > > > An embedded processor executes machine code > > from a C complier or an assembler. > > If I have an external computer reading the register, > > I don't need a cpu core on the fpga anyway. > > > VHDL code might *describe* a cpu, but it does not run on one. > > > -- Mike Treseler > > Thanks for the response! What's wrong with using the PC to implement the web server? A web server is a complex device when viewed from the gate level which is typically several layers down from the level of web software. If you intend to include an embedded processor in the FPGA, then you can run any software you want. Mike explained that VHDL is not the sort of software you would want to use to run a web application. The HDL stands for "Hardware Description Language". Nowhere in there does it indicate that it would be useful or remotely easy to implement a web server. The counters are perfect for an FPGA design. The idea of loading the counts into a DDR ram and accessing them is now outside of the FPGA and at the board level. Is there a reason not to use the internal memory in the FPGA? Will this be running in batch mode where you run the measurement for a while, stop and read out the results; or will you be reading the results in real time as the measurement is being made? If the latter, your comms has to keep up with the average rate of the measurement and the ram is only a buffer to smooth out the measurement data rate. RickArticle: 142231
Griffin wrote: > It's actually 7 24-bit counters to worry about. My sampling rate is on > the order of a few every microsecond, which I'm pretty sure will > require the ram to function as a buffer. got $15 ? http://www.amazon.com/Startech-Parallel-Interface-Adapter-Cable/dp/B00005110LArticle: 142232
On Jul 30, 5:24=A0am, "Pete Fraser" <pfra...@covad.net> wrote: > It's a shame it doesn't start slightly earlier. > What and when was the first PLD (not including ROMs). > I remember using the Signetics 82S series (100?, 105? > 153?) back sometime in the mid 70's. Was Signetics the > first? I think the MMI stuff was a bit later. There is a hole in their timelines, as Signetics became Philips/ Signetics without a 5 year gap!\ I see jameco still show stock of N82S100 ! - and QPsemi have some legacy-pathway products http://www.qpsemi.com/pld.asp I think they even did a re-spin of the 82S100 :) -jgArticle: 142233
On Jul 29, 10:35=A0am, Frank Buss <f...@frank-buss.de> wrote: > Frank Buss wrote: > > Is this corruption problem on read really a "feature" of all FPGAs with > > BRAM from all vendors? > > Just answering my question myself: Yes, Altera block RAMs have this > problem, too, see e.g. page 9: > > http://www.altera.com/literature/hb/cyc2/cyc2_cii51008.pdf > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.de When I used the word "feature" in quotation marks, I was facetious... This problem is not intuitively obvious, and is caused by metastability, i.e. it occurs very rarely. That's why it took a long time to detect and document. This is what can cause the problem: The address inputs change just before the rising edge of the enabled clock, exactly during the (less than a femtosecond-wide) metastability-catching timing window. The address-register Q outputs inside the BRAM now behave unpredictably, and the address decoder can overlap and activate two of its decoded outputs at the same (very short) time. These two decoder outputs connect two memory cells simultaneously onto the common read bus. The stronger of the memory cells can then backwards-load its content into the weaker cell. Note that this is not the conventional write mechanism, which of course is disabled. The problem is obscure, but really basic, and I am not aware of any fix that would maintain the performance of the BRAM. We have to guarantee >500 MHz clock rate, which does not leave much margin for circuit tricks. Altera has and admits the same problem. I have googled and checked the Cypress website, without success. It is difficult to build reliable high-performance systems, if they are driven from an unreliable clock source. Peter AlfkeArticle: 142234
> So for most cost sensitive apps, a company will do better to compete > the FPGA vendors against each other or you will be giving them the fat > on your designs. That is some pretty good advice. It's probably been that way for a long time. Personal preference often doesn't play a role with respect to economics.Article: 142235
Griffin wrote: > Hello, hello, > > I'm a grad student and am pretty new to the FPGA scene > Wow! There's a scene. Cool. :-) p.s. What they said ^^^Article: 142236
On 7=D4=C230=C8=D5, =C9=CF=CE=E712=CA=B116=B7=D6, "Antti.Luk...@googlemail.= com" <Antti.Luk...@googlemail.com> wrote: > On Jul 29, 5:37 pm, arcdoos <arcd...@yahoo.com> wrote: > > > It has worked at Xilinx ML605 board. plz mail me if more info. > > > arcd...@yahoo.com > > you should get prize on wrong way to announce, what is what has > worked? > > 1) you developed some IP and it works well? > 2) you stole IP some and want to sell it? > 3) or you need something? > > its totally unclear from your writeup what it is! > pardon me, but from your style, i would guess [2] > but even if so, it can be announced better :) > > Antti what is IP?Article: 142237
Peter Alfke wrote: > This is what can cause the problem: > The address inputs change just before the rising edge of the enabled > clock, exactly during the (less than a femtosecond-wide) > metastability-catching timing window. > The address-register Q outputs inside the BRAM now behave > unpredictably, and the address decoder can overlap and activate two of > its decoded outputs at the same (very short) time. > These two decoder outputs connect two memory cells simultaneously onto > the common read bus. The stronger of the memory cells can then > backwards-load its content into the weaker cell. Note that this is not > the conventional write mechanism, which of course is disabled. Thanks for the good explanation, now I understand the reason of the problem. Do you think the problem is still possible with BRAMs clocked from PLLs of the same FPGA, or is a PLL a good filter for unreliable external clocks and I could at least use the unlocked output to detect all possible problems? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142238
On Jul 29, 7:52=A0pm, Frank Buss <f...@frank-buss.de> wrote: > Peter Alfke wrote: > > This is what can cause the problem: > > The address inputs change just before the rising edge of the enabled > > clock, exactly during the =A0(less than a femtosecond-wide) > > metastability-catching timing window. > > The address-register Q outputs inside the BRAM now behave > > unpredictably, and the address decoder can overlap and activate two of > > its decoded outputs at the same (very short) time. > > These two decoder outputs connect two memory cells simultaneously onto > > the common read bus. The stronger of the memory cells can then > > backwards-load its content into the weaker cell. Note that this is not > > the conventional write mechanism, which of course is disabled. > > Thanks for the good explanation, now I understand the reason of the > problem. Do you think the problem is still possible with BRAMs clocked fr= om > PLLs of the same FPGA, or is a PLL a good filter for unreliable external > clocks and I could at least use the unlocked output to detect all possibl= e > problems? > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.de Frank, we all know that a PLL is a good flywheel, and reduces or suppresses jitter and other clocking abnormalities. Whether it is sufficient must depend on the character of the original timing problem. If you want to experiment, create a simple test circuit, not this BlockROM where the MTBF can easily be extremely long. Gruss PeterArticle: 142239
On Jul 30, 4:19 am, arcdoos <arcd...@yahoo.com> wrote: > On 7=D4=C230=C8=D5, =C9=CF=CE=E712=CA=B116=B7=D6, "Antti.Luk...@googlemai= l.com" > > > > > > <Antti.Luk...@googlemail.com> wrote: > > On Jul 29, 5:37 pm, arcdoos <arcd...@yahoo.com> wrote: > > > > It has worked at Xilinx ML605 board. plz mail me if more info. > > > > arcd...@yahoo.com > > > you should get prize on wrong way to announce, what is what has > > worked? > > > 1) you developed some IP and it works well? > > 2) you stole IP some and want to sell it? > > 3) or you need something? > > > its totally unclear from your writeup what it is! > > pardon me, but from your style, i would guess [2] > > but even if so, it can be announced better :) > > > Antti > > what is IP?- Hide quoted text - > > - Show quoted text - You got the PRIZE :) AnttiArticle: 142240
On Wed, 29 Jul 2009 18:41:10 -0600, Nicholas Kinar <n.kinar@usask.ca> wrote: > >> So for most cost sensitive apps, a company will do better to compete >> the FPGA vendors against each other or you will be giving them the fat >> on your designs. > > >That is some pretty good advice. It's probably been that way for a long= =20 >time. Personal preference often doesn't play a role with respect to=20 >economics. You can bet it gets seriously minimized versus accountant's cost reductions.Article: 142241
On Jul 30, 11:43=A0am, Peter Alfke <pe...@xilinx.com> wrote: > > This is what can cause the problem: > The address inputs change just before the rising edge of the enabled > clock, exactly during the =A0(less than a femtosecond-wide) > metastability-catching timing window. > The address-register Q outputs inside the BRAM now behave > unpredictably, and the address decoder can overlap and activate two of > its decoded outputs at the same (very short) time. > These two decoder outputs connect two memory cells simultaneously onto > the common read bus. The stronger of the memory cells can then > backwards-load its content into the weaker cell. Note that this is not > the conventional write mechanism, which of course is disabled. > > The problem is obscure, but really basic, and I am not aware of any > fix that would maintain the performance of the BRAM. So you have a Phantom-Write pathway, that is essentially a make-before- break analog switch ? I am also surprised the Memory cell itself can drive to/from a read- bus, usually those are orders of magnitude different loads ? The analog switch guys have been making break-before-make pathways for many years now... I'm sure some are looking for work ;) -jgArticle: 142242
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:a1e404d5-f739-4763-8eb5-e7db06f8e186@b14g2000yqd.googlegroups.com... > Hi > > I guess the way i do it, there is little feedback to be expected, ;) > but, eh, its getting to be one year full now, the 1 year issue to be > out soon, > and still not have had time to get the LAYOUT and editorial templates > all > ironed out, made beatiful.. just tipping in things from my mind as it > goes > > so, any commentary? wishes? > ideas to submit? i am listening, as always > > writing up july issue right now > > Antti Hello Antti, Please don't give up !!!!! Apart from joy of VHDL the one thing that keeps me going is when I see that "Antti" in the 'From' column on my newsreader. Sorry I don't feed back very often - I'll try to do better after the July one. Michael Kellett (having spent most of last week making UDP work on dsPIC33 with horrid SPI ethernet chip and looking forward to doing some nicer work this week !) www.mkesc.co.ukArticle: 142243
>On Jul 28, 1:54=A0pm, Andy <jonesa...@comcast.net> wrote: >> Watch out for delta delays on your clock between the top level and >> lower levels (i.e. from an assignment of one clock signal from >> another). The delta delay incurred by the clock will cause it not to >> see inputs on the same clock cycle in RTL simulation. >> >> Andy > >Don't forget to have hold time in your testbench signals. You >don't need delays, just a dependency on the clock edge. If you >generate both the clock and the start signal together, you should >expect the timing you're seeing. If start depends on clock'event >then you should see the behavior of the lower level module. > Thank you very much, that was probably the problem. I simply shifted by an insignificant amount of time all the input signals and the response became as expected. Maybe later I'll write them in a way that make them dependent on a clk'event. And all states are signals. Thanks everybodyArticle: 142244
Antti <Antti.Lukats@googlemail.com> wrote: > Hi > I guess the way i do it, there is little feedback to be expected, ;) > but, eh, its getting to be one year full now, the 1 year issue to be > out soon, > and still not have had time to get the LAYOUT and editorial templates > all > ironed out, made beatiful.. just tipping in things from my mind as it > goes > so, any commentary? wishes? > ideas to submit? i am listening, as always > writing up july issue right now I enjoz reading too. Please keep going. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142245
On Jul 28, 10:18=A0am, Ben <leowy...@gmail.com> wrote: > I've read about daisy chaining fpgas with Platform flash, but is daisy > chaining fpgas possible with SPI flash? > The documents at Xilinx seems to give only examples of single fpga > configuration with SPI flash. Yes Daisy Chaining using SPI flash is possible go thru the 3E datasheet configuration option. Only take care that FPGA should not be stepping 0.Article: 142246
On Jul 28, 9:44=A0pm, gabor <ga...@alacron.com> wrote: > On Jul 28, 12:24=A0pm, "Antti.Luk...@googlemail.com" > > > > > > <Antti.Luk...@googlemail.com> wrote: > > On Jul 28, 7:00=A0pm, Ben <leowy...@gmail.com> wrote: > > > > On Jul 28, 11:49=A0pm, gabor <ga...@alacron.com> wrote: > > > > > On Jul 28, 11:33=A0am, "Antti.Luk...@googlemail.com" > > > > > <Antti.Luk...@googlemail.com> wrote: > > > > > On Jul 28, 6:18=A0pm, Ben <leowy...@gmail.com> wrote: > > > > > > > I've read about daisy chaining fpgas with Platform flash, but i= s daisy > > > > > > chaining fpgas possible with SPI flash? > > > > > > The documents at Xilinx seems to give only examples of single f= pga > > > > > > configuration with SPI flash. > > > > > > no, you cant use multiply SPI flash in chained mode > > > > > (you may configure more than one FPGA from one SPI flash) > > > > > > well, some newer FPGA's include multi SPI support, > > > > > > * Spartan-6 > > > > > * Lattice-SC > > > > > * Achronix Speedster > > > > > > all support multiply SPI flash in __parallel__ wiring > > > > > (maybe some others too, i do not know all ) > > > > > > Antti > > > > > I'm not sure that was what he was asking. =A0If you have a single > > > > SPI flash big enough to hold all the bitstreams you can daisy > > > > chain the FPGA's (not the flash chips). =A0One FPGA is in SPI maste= r > > > > mode and the others in serial slave mode. =A0Should be shown in the > > > > configuration UG. > > > > Yes, I see this line "Another alternative is to use SPI mode for the > > > first device. The daisy-chain data is still sent out through DOUT in > > > SPI mode." > > > Well, this is in the Serial Daisy Chain section and they use a Xilinx > > > Platform Flash PROM.- Hide quoted text - > > > > - Show quoted text - > > > Xilinx FPGA configuration controller has special function to BYPASS > > config data > > so you can stream it from the first device and use for any purpose you > > need > > (as config another FPGA as example) > > > it is ir-relevant if the configuration comes from platform flash or > > spi flash > > > or, you can use another approuch what i used with lattice FPGA > > as soon as FIRST FPGA is configured, it ROUTES the spi flash > > out to some downstream FPGA config interface and starts generating > > SPI clock, this "user config controller" is very small and doesnt take > > much resources > > > Antti > > Actually at least for ECP2, SPI config of multiple parts is easy > with Lattice. =A0The first FPGA is in SPI master mode and the > subsequent FPGA's are in serial slave mode. =A0First FPGA CCLK > is both =A0SPI clock and downstream CCLK for serial config. =A0The > tricky part with lattice is figuring out how to merge the > bitstreams into the single SPI PROM (you need the "Universal > File Writer" for this). > > Regards, > Gabor- Hide quoted text - > > - Show quoted text - well, in my case the device downstream was Virtex-4 :) i think i used own tools to merge the bits AnttiArticle: 142247
What is it about and were can I read about it ?Article: 142248
On Jul 30, 3:23=A0pm, Jaerder Sousa <jaer...@netcabo.pt> wrote: > What is it about? ( if itshttp://antti-brain.com/, how does one get a > log-in) ? you got me :) http://groups.google.com/group/antti-brain?hl=3Den ok here, the PDF files are downloadable for all past issues, no login required. on www.antti-brain.com I did install moodle for testing, and forgot to remove it, eh the web based web management is painful with slow gsm-internet connection SORRY Antti july issue maybe little delayed again, but it comes...Article: 142249
On Jul 27, 5:10=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Jul 24, 12:21=A0am, bishopg <bishop...@gmail.com> wrote: > > > > > I am currently working on a design using the v4fx20. =A0My current > > design consists of bram memory at 0xffff0000 to 0xffffffff and DDR at > > 0x00000000 to 0x03ffffff. =A0I can read and write from the bram memory, > > but whenever I either read or write from anywhere within the DDR > > memory space, my entire memory space (0x00000000 - 0xffffffff) becomes > > unusable. =A0For example: > > > XMD% mrd 0xffffff00 16 > > FFFFFF00: 00000000 > > FFFFFF04: 00000000 > > FFFFFF08: 00000000 > > FFFFFF0C: 00000000 > > FFFFFF10: 00000000 > > FFFFFF14: 00000000 > > FFFFFF18: 00000000 > > FFFFFF1C: 00000000 > > FFFFFF20: 00000000 > > FFFFFF24: 00000000 > > FFFFFF28: 00000000 > > FFFFFF2C: 00000000 > > FFFFFF30: 00000000 > > FFFFFF34: 00000000 > > FFFFFF38: 00000000 > > FFFFFF3C: 00000000 > > > XMD% mwr 0xffffff00 0x12345678 > > XMD% mrd 0xffffff00 16 > > FFFFFF00: 12345678 > > FFFFFF04: 00000000 > > FFFFFF08: 00000000 > > FFFFFF0C: 00000000 > > FFFFFF10: 00000000 > > FFFFFF14: 00000000 > > FFFFFF18: 00000000 > > FFFFFF1C: 00000000 > > FFFFFF20: 00000000 > > FFFFFF24: 00000000 > > FFFFFF28: 00000000 > > FFFFFF2C: 00000000 > > FFFFFF30: 00000000 > > FFFFFF34: 00000000 > > FFFFFF38: 00000000 > > FFFFFF3C: 00000000 > > > XMD% mrd 0x00000000 16 > > 0: FFFFFFF8 > > 4: FFFFFFF8 > > 8: FFFFFFF8 > > C: FFFFFFF8 > > 10: FFFFFFF8 > > 14: FFFFFFF8 > > 18: FFFFFFF8 > > 1C: FFFFFFF8 > > 20: FFFFFFF8 > > 24: FFFFFFF8 > > 28: FFFFFFF8 > > 2C: FFFFFFF8 > > 30: FFFFFFF8 > > 34: FFFFFFF8 > > 38: FFFFFFF8 > > 3C: FFFFFFF8 > > > XMD% mrd 0xffffff00 16 > > FFFFFF00: FFFF0958 > > FFFFFF04: FFFF0958 > > FFFFFF08: FFFF0958 > > FFFFFF0C: FFFF0958 > > FFFFFF10: FFFF0958 > > FFFFFF14: FFFF0958 > > FFFFFF18: FFFF0958 > > FFFFFF1C: FFFF0958 > > FFFFFF20: FFFF0958 > > FFFFFF24: FFFF0958 > > FFFFFF28: FFFF0958 > > FFFFFF2C: FFFF0958 > > FFFFFF30: FFFF0958 > > FFFFFF34: FFFF0958 > > FFFFFF38: FFFF0958 > > FFFFFF3C: FFFF0958 > > > To me this sounds like a timing issue, but I believe I have everything > > constrained that needs to be constrained. =A0It could also be a > > initialization issue but I'm not sure. =A0Has anyone run into such an > > issue? > > MPMC memory is not working, it will lock up the bus on first access to > it > its a known > > "feature" > > Antti Just figured that out. The InitDone signal was not high. Thanks, -George
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