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
> I am looking for my usual FPGA in a small package. This is a contract > design and the customer has a preference to avoid BGAs. The only > leaded part that will fit the board is a 100 pin TQFP. I found a > couple of MAX II devices in this package and Lattice has some MACHXO > parts as well as one XP part. Of the three, I like the XP better as > it has 3000 LUTs to work with as well as PLLs. You might find that Actel suits your needs ... http://www.actel.com/documents/selguide.pdf (It looks as though Actel carries some smaller ProASICPlus parts in a TQFP 100 package. Those parts have 2 PLLs and are Flash-based [reprogrammable, immune to SEUs, etc.].) K.Article: 125901
On Nov 8, 4:08 am, Maki <prase.ruzica...@gmail.com> wrote: > <snip> > > > Looking at the tools, it is not clear to me if I can really evaluate > > them using ispLever Starter. This package seems to not include the > > full set of tools including the simulator and programmer. So I can't > > actually program a device with the starter tool, right? Is the > > simulator that comes with the ispLever package limited in any way? > > The web site does not describe it very well. > > No simulator but programmer is there. As for a hardware they offer a > cheap parallel and pricey USB programmer. I've used ispLever Starter > in several projects IMHO it is a good tool. > > Regards, > Maki But if there is no simulator, how can you really do anything useful with the Starter kit? If you just want to play with the software it would be fine, but if you really want to evaluate the package, you need to do a small project which requires a simulator, no? I just don't have the time to spend playing with tools other than for a project of some sort. My customer told me he tried the Lattice parts once and had a problem using the tools, so I would want to give them a thorough going over and still be prepared to switch to a different brand of part if the tools proved wonky. In another thread early this year, I was reading that the parallel port has gone they way of the dodo bird (at least on laptops) and none of the alternate parallel port solutions really work reliably. So I want to avoid them at all costs. I'll look at the USB programmer. I haven't had a chance to read up on programming the little buggers. Do these programmers work through the JTAG port on the parts?Article: 125902
JJ, The spec you reference is the diode clamp, not the driver. However, you may do what you are suggesting, and not damage the FPGA. There are many IO standards with currents of up to 60 mA (source/sink), and the device is designed with margin so that these interfaces will run for more then twenty years without a reliability concern. Although not recommended (and certainly not warrantied), we have seen IOs shorted to ground, or Vcc, and placed in the opposite driving state, and shipped to customers, returned, and tested just fine. A directly shorted output, when programmed for 24 mA LVCMOS (the strongest standard) will max out at about 120 mA of source current at nominal process/voltage/temperature. If programmed for less current, then the short circuit current will also be less. If you want to see what kind of drive current you get, you need to use the IBIS models to simulate your particular circuit, with your IO standard. With IBIS, there is also the FAST/STRONG process/voltage/temperature corner modeled, so you can see what the largest current is likely to be when you get a fast process part, operate at high voltages, and low temperatures. For example, a 2.5V LVCMOS 12 mA Spartan3 IO driving into a 1 ohm to ground sources ~ 70 mA at the FAST/STRONG IBIS PVT corner (Mentor/HyperLynx with latest IBIS models). AustinArticle: 125903
JJ, You do not need to protect against momentary shorts to ground, or Vcco (as long as you are within our abs max limits -- which you may well be for a LVCMOS 23.5V 12 mA output as mentioned in the previous post). What will KILL any CMOS part, is a momentary short to a negative voltage, which causes currents in excess of 200 mA to flow (in telecom, with -48 battery everywhere, this is a real concern, as it is instant death to short to -48V!!!!). Next, Xilinx abs max specs are perhaps different from some of our competition: they are the limits at which there is no damage, or reliability concerns (ie at these extremes, less than 0.1% of the parts will fail after 20 years under these conditions). Often, manufacturers use the "abs max" as where the damage exceeds the 0.1%/year at end of life, as it looks so much better (it makes their parts appear more robust, when they are not that robust at all -- we all use a standard foundry process, and all use similar design rules, so we all have really the similar behavior when it comes to overstress, reliability and failure). TANSTAFL AustinArticle: 125904
<jidan1@hotmail.com> wrote in message news:1194531574.418147.153370@z24g2000prh.googlegroups.com... > > I don't want actually to drive a load with 100mA;the thing is that I > will connect different boards on this board with the FPGA. I want to > protect the FPGA output pins from short-circuits to GND, without > effecting the maximum datatransfer (100 MHz). The simplest solution I > found is connecting a series resistor. The question now is what > resistor value should I use. If I used a resistor as high as 150 Ohm > (~3.3V/24ma) I might not be able to transfer data rate up to 100 MHz. > Yous see what my problem is! > > JJ If you want to spend time protecting your design from short-circuited pins, consider a different approach: make your outputs I/O signals. Monitor the output levels as detected by the inputs. If the signal is truly grounded, a high output drive won't bring the voltage level above threshold under DC drive. A similar argument works for shorts to VCC. While the expected output state and the corresponding input are typicall off by a couple nanoseconds, the signal level should always be established at the next clock for slow clocks and within 2 periods for faster clocks that are expected to establish their level at the receiver within the 1 clock period. You end up without compromise on your connection speed and can offer a fault monitor to the user. Check with your manufacturer, but the absolute maximums should be for the DC case, not the temporary short for a couple clocks; my understanding is that modern FPGAs can drive those direct shorts for a period of time with no issues - it's the extended drive that can cause severe problems. - John_HArticle: 125905
Hi All, I've got the Spartan 3E-500 starter kit from Digilent and need to use the DDR ram on the board. I've searched this group and found lots of references to a port of the opencores DDR controller, which has been ported to this board, but after (a lot of) google searching I can't find anything other than a reference to the fact that it has been done - does anyone know where I can get hold of the code? Many thanks, MaxArticle: 125906
"Kryvor" <kris.vorwerk@gmail.com> wrote in message news:1194534882.138541.287930@i13g2000prf.googlegroups.com... <snip> > > (It looks as though Actel carries some smaller ProASICPlus parts in a > TQFP 100 package. Those parts have 2 PLLs and are Flash-based > [reprogrammable, immune to SEUs, etc.].) The Flash cells may be imune to SEUs but the active logic certainly isn't. SEUs "tend" to be noticed in SRAM cells first but registers are also affected by the same radiation for FPGAs of any flavor as well as ASICs and other standard parts. - John_HArticle: 125907
On Nov 8, 4:56 pm, rickman <gnu...@gmail.com> wrote: > On Nov 8, 4:08 am, Maki <prase.ruzica...@gmail.com> wrote: > > > <snip> > > > > Looking at the tools, it is not clear to me if I can really evaluate > > > them using ispLever Starter. This package seems to not include the > > > full set of tools including the simulator and programmer. So I can't > > > actually program a device with the starter tool, right? Is the > > > simulator that comes with the ispLever package limited in any way? > > > The web site does not describe it very well. > > > No simulator but programmer is there. As for a hardware they offer a > > cheap parallel and pricey USB programmer. I've used ispLever Starter > > in several projects IMHO it is a good tool. > > > Regards, > > Maki > > But if there is no simulator, how can you really do anything useful > with the Starter kit? If you just want to play with the software it > would be fine, but if you really want to evaluate the package, you > need to do a small project which requires a simulator, no? I just > don't have the time to spend playing with tools other than for a > project of some sort. My customer told me he tried the Lattice parts > once and had a problem using the tools, so I would want to give them a > thorough going over and still be prepared to switch to a different > brand of part if the tools proved wonky. > In another thread early this year, I was reading that the parallel > port has gone they way of the dodo bird (at least on laptops) and none > of the alternate parallel port solutions really work reliably. So I > want to avoid them at all costs. I'll look at the USB programmer. I > haven't had a chance to read up on programming the little buggers. Do > these programmers work through the JTAG port on the parts? I use external tool for simulation and an USB programmer. Yes programmer uses JTAG or slave serial. Regards, MakiArticle: 125908
On Nov 7, 3:34 am, John Devereux <jdREM...@THISdevereux.me.uk> wrote: > John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes: > > On Tue, 06 Nov 2007 13:45:28 -0800, a7yvm109gf...@netzero.com wrote: > > >>On Nov 6, 12:59 pm, Andy <jonesa...@comcast.net> wrote: > > >>> Prior to that, how many existing boards do you need to use up, and how > >>> many customers can you afford to loose when they do not work > > >>About as many as he can afford to tighten, I suppose. > > > The chances of this not working are nil; I'd be more worried about > > meteor damage in shipping. > > In fact I would think it is more likely that the "proper" LDO solution > will e.g. start oscillating, for some reason. > > -- > > John Devereux If the LDO starts oscillating "for some reason", it is either a faulty (i.e. not meeting its specs) component, or the design was incorrect (failing to take into account the entire range of operating conditions, tolerances, tempcos, drift/aging, etc.) which is much more common, particularly among advocates of using forward biased zener diodes for power supplies. The diode circuit cannot be designed correctly (because it is being operated outside its specifications). If you are saying it is easier to "get it working" for a diode circuit than an LDO, you may be correct, under the right conditions (which generally disappear the moment the product is shipped). As mentioned earlier, continuously forward biasing a diode designed to operate reverse-biased may cause long term problems. AndyArticle: 125909
On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesandy@comcast.net> wrote: >On Nov 7, 3:34 am, John Devereux <jdREM...@THISdevereux.me.uk> wrote: >> John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes: >> > On Tue, 06 Nov 2007 13:45:28 -0800, a7yvm109gf...@netzero.com wrote: >> >> >>On Nov 6, 12:59 pm, Andy <jonesa...@comcast.net> wrote: >> >> >>> Prior to that, how many existing boards do you need to use up, and how >> >>> many customers can you afford to loose when they do not work >> >> >>About as many as he can afford to tighten, I suppose. >> >> > The chances of this not working are nil; I'd be more worried about >> > meteor damage in shipping. >> >> In fact I would think it is more likely that the "proper" LDO solution >> will e.g. start oscillating, for some reason. >> >> -- >> >> John Devereux > >If the LDO starts oscillating "for some reason", it is either a faulty >(i.e. not meeting its specs) component, or the design was incorrect >(failing to take into account the entire range of operating >conditions, tolerances, tempcos, drift/aging, etc.) which is much more >common, particularly among advocates of using forward biased zener >diodes for power supplies. > >The diode circuit cannot be designed correctly (because it is being >operated outside its specifications). > >If you are saying it is easier to "get it working" for a diode circuit >than an LDO, you may be correct, under the right conditions (which >generally disappear the moment the product is shipped). > >As mentioned earlier, continuously forward biasing a diode designed to >operate reverse-biased may cause long term problems. > >Andy What makes you think zeners should not be operated in forward bias? The normal zener supply off line voltage switches between forward and reverse bias at line frequency. Do you have any reason to suspect there would be problem? Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.comArticle: 125910
On Thu, 08 Nov 2007 17:09:20 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:
>On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesandy@comcast.net>
>wrote:
>
>>On Nov 7, 3:34 am, John Devereux <jdREM...@THISdevereux.me.uk> wrote:
>>> John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
>>> > On Tue, 06 Nov 2007 13:45:28 -0800, a7yvm109gf...@netzero.com wrote:
>>>
>>> >>On Nov 6, 12:59 pm, Andy <jonesa...@comcast.net> wrote:
>>>
>>> >>> Prior to that, how many existing boards do you need to use up, and how
>>> >>> many customers can you afford to loose when they do not work
>>>
>>> >>About as many as he can afford to tighten, I suppose.
>>>
>>> > The chances of this not working are nil; I'd be more worried about
>>> > meteor damage in shipping.
>>>
>>> In fact I would think it is more likely that the "proper" LDO solution
>>> will e.g. start oscillating, for some reason.
>>>
>>> --
>>>
>>> John Devereux
>>
>>If the LDO starts oscillating "for some reason", it is either a faulty
>>(i.e. not meeting its specs) component, or the design was incorrect
>>(failing to take into account the entire range of operating
>>conditions, tolerances, tempcos, drift/aging, etc.) which is much more
>>common, particularly among advocates of using forward biased zener
>>diodes for power supplies.
>>
>>The diode circuit cannot be designed correctly (because it is being
>>operated outside its specifications).
>>
>>If you are saying it is easier to "get it working" for a diode circuit
>>than an LDO, you may be correct, under the right conditions (which
>>generally disappear the moment the product is shipped).
>>
>>As mentioned earlier, continuously forward biasing a diode designed to
>>operate reverse-biased may cause long term problems.
>>
>>Andy
>
>What makes you think zeners should not be operated in forward bias?
>The normal zener supply off line voltage switches between forward and
>reverse bias at line frequency. Do you have any reason to suspect
>there would be problem?
^^^ any
(Maybe I'm dealing with too many people these days who are not
fortunate enough to have the Queen's English as their mother tongue).
;-)
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Article: 125911On Nov 7, 9:16 pm, Alain <no_spa2...@yahoo.fr> wrote: > go to : > > http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp > > then look at : > > EDK (Platform Studio) > Integrated development environment containing tools to facilitate the > creation of your embedded platform > Current: > 9.2i - Nov 2007 > Learn more | Download I just installed EDK 9.2i. You can read more in my blog: http://svenand.blogdrive.com/archive/89.html SvenArticle: 125912
On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesandy@comcast.net>
wrote:
>On Nov 7, 3:34 am, John Devereux <jdREM...@THISdevereux.me.uk> wrote:
>> John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
>> > On Tue, 06 Nov 2007 13:45:28 -0800, a7yvm109gf...@netzero.com wrote:
>>
>> >>On Nov 6, 12:59 pm, Andy <jonesa...@comcast.net> wrote:
>>
>> >>> Prior to that, how many existing boards do you need to use up, and how
>> >>> many customers can you afford to loose when they do not work
>>
>> >>About as many as he can afford to tighten, I suppose.
>>
>> > The chances of this not working are nil; I'd be more worried about
>> > meteor damage in shipping.
>>
>> In fact I would think it is more likely that the "proper" LDO solution
>> will e.g. start oscillating, for some reason.
>>
>> --
>>
>> John Devereux
>
>If the LDO starts oscillating "for some reason", it is either a faulty
>(i.e. not meeting its specs) component, or the design was incorrect
>(failing to take into account the entire range of operating
>conditions, tolerances, tempcos, drift/aging, etc.) which is much more
>common, particularly among advocates of using forward biased zener
>diodes for power supplies.
There are lots of tricky/flakey/poorly specified LDOs being sold in
volume. Many/most are very sensitive to the capacitive+esr load
environment, and many of the datasheets are fuzzy about that. Ditto
switchers.
>
>The diode circuit cannot be designed correctly (because it is being
>operated outside its specifications).
What a bizarre thing to say. I'm an electrical engineer, and I do
stuff like this all the time. The behavior of forward-biased PN
junctions is fairly well known by now. And as Austin pointed out, the
actual operating range of Vccaux is huge.
>
>If you are saying it is easier to "get it working" for a diode circuit
>than an LDO, you may be correct, under the right conditions (which
>generally disappear the moment the product is shipped).
>
>As mentioned earlier, continuously forward biasing a diode designed to
>operate reverse-biased may cause long term problems.
Why would it do that? What would be the failure mechanism? What would
be the failure mode?
Incidentally, zeners are use in the forward direction all the time,
like in bidirectional clippers and transzorbs.
John
From m.nguyen@arcor.de Thu Nov 08 15:59:47 2007
Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!news.belwue.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Message-Id: <4733a2b0$0$4363$9b4e6d93@newsspool4.arcor-online.net>
From: Minh Nguyen <m.nguyen@arcor.de>
Subject: Re: [Linker script : EDK6.3 -> EDK 8.2] Parse error
Newsgroups: comp.arch.fpga
Date: Fri, 09 Nov 2007 00:59:47 +0100
References: <1194447086.022967.113470@y42g2000hsy.googlegroups.com>
User-Agent: KNode/0.10.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 35
Organization: Arcor
NNTP-Posting-Date: 09 Nov 2007 00:58:40 CET
NNTP-Posting-Host: add9a6bc.newsspool4.arcor-online.net
X-Trace: DXC=ghdBD3E3ff3QbA1[CgMQ004IUK<Cl32<14Fo<]lROoR1^;5]aA^R6>2elUoFDNI;n0_MY<Koln^^5Xlld0l^PSI9AGTUe<PVQH0
X-Complaints-To: usenet-abuse@arcor.de
Xref: prodigy.net comp.arch.fpga:137914
X-Received-Date: Thu, 08 Nov 2007 18:58:42 EST (newsdbm02.news.prodigy.net)
On Wed 07 Nov 2007 15:51 Pasacco wrote:
> Dear
>
> I used to EDK 6.3 for multiprocessor system implementation.
> The system worked fine.
> But, when I upgraded to EDK 8.2, "parse error" occurs in the following
> linker script.
>
> ------------------------------------------------------------------------
> .init : { KEEP(*(.init)) } >
> .fini : { KEEP(*(.fini)) } >
^
Here is the full syntax of a section definition:
SECTION [ADDRESS] [(TYPE)] :
[AT(LMA)] [ALIGN(SECTION_ALIGN)] [SUBALIGN(SUBSECTION_ALIGN)]
{
OUTPUT-SECTION-COMMAND
OUTPUT-SECTION-COMMAND
...
} [>REGION] [AT>LMA_REGION] [:PHDR :PHDR ...] [=FILLEXP]
You need to specify a region or just delete the '>'s.
HTH
> ------------------------------------------------------------------------
>
> Does anyone have this experience? If yes, let me know how to fix this
> problem.
>
> Thank you in advance.
>
> Entire linker script is below.
[snip]
Article: 125913On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: > i want to read & write data to/from a fifo placed in fpga. MCU's > external bus is connected to the chip. I am using the sync-fifo ip of > Altera CycloneII. The data bus and control signal are connected to > fifo directly. it's unfortune that when i read once from bus, data > would be read twice from fifo because there are two clock rising edges > during read signal(low active) is resetted. I think it will read more > datas from fifo if the read signal is resetted long enough. > Is there any good design for fifo interface connecting on the > exteranl bus? Using a Synchronous FIFO implies that the read clock and the write clock are in the same clock domain. Is your MCU supplying the FIFO's clock or is the FPGA supplying the MCU's clock? If the clock sources are different, then you either need an Asynchronous FIFO, or you need to run the MCU and FPGA from the same clock. HTH -Dave PollumArticle: 125914
Hi Mordehay, me_2003@walla.co.il wrote: >>>I would like to debug a system containing a microblze and a ppc405. >>>I'm >>>using the xmd (gdb) for both of these units. I have a single mdm unit >>>and a jtagppc (a single jtag interface). >>>Is there a way to debug both of the processors simultaneously (via >>>two >>>GDBs). >> >>You shld be able to do this - using xmd, connect to both CPUs: >> >>% connect mb mdm >>% connect ppc hw >> >>you may need to add other options to each connect statement, depending >>on your FPGA and JTAG setup etc. >> > Another little thing - can the mdm & jtagppc live together ? Yes, I believe so. > how does > the jtag chain looks like ? MDM connects to the user1 port on the FPGA's JTAG chain, while the JTAGPPC should insert the PPC as its own device in the chain. I'm not certain of the exact order, but xmd should take care of that detail. Regards, JohnArticle: 125915
The documentation for the P160 Comm 3 is still posted on the Avnet DRC (www.em.avnet.com/drc), but the module is not for sale anymore. You could try checking with your Avnet FAE or try finding a used one somewhere. The P160 Comm 2 is still available, but it has a PHY rather than MAC +PHY. Another alternative (but different hardware), is the Spartan-3 Mini- Module. This has the same MAC+PHY as the P160 Comm 3. http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25724%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html Bryan Sean Durkin wrote: > ratemonotonic wrote: > > Oh no ! I Have done a preliminary system design with the assumption > > that a addon ethernet MAC/PHY Chip like P160 comms 3 module will be > > available, for my memec Spartan 3 LC devlopment kit. Is there any way > > out of this dilemma? > When I asked my FAE about a year ago, I got the following response: > > Re: XILINX MEMEC Boards Future: > We have developed a new expansion standard called EXP. All new boards > will use this format, and AvBus and P160/P240 will go away. We have > created a EXP-to-P160 adaptor to allow P160 modules to connect to the > new EXP boards. You can see more info on EXP at www.em.avnet.com/exp > > HTH, > Sean > > -- > My email address is only valid until the end of the month. > Try figuring out what the address is going to be after that...Article: 125916
On Nov 8, 7:27 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > Does anyone know if it is possible to configure a Virtex 4 using a Spartan > 3E. I want to connect a Flash memory to the Spartan and set this to be the > master. Once configured I want the Virtex 4 that is the slave to > configure. > > Cheers > > Jon This is possible with a parallel flash using Spartan-3E BPI mode. See Xilinx UG332, Master BPI Mode, Daisy Chaining. BryanArticle: 125917
Now that Microblaze has support for either PLB or OPB, what are the advantages and disadvantages of PLB? I started looking at the PLB specification, but I don't yet understand it well enough to have any feel for how it compares to OPB, or why it might be preferred. Thanks, EricArticle: 125918
On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: > > > i want to read & write data to/from a fifo placed in fpga. MCU's > > external bus is connected to the chip. I am using the sync-fifo ip of > > Altera CycloneII. The data bus and control signal are connected to > > fifo directly. it's unfortune that when i read once from bus, data > > would be read twice from fifo because there are two clock rising edges > > during read signal(low active) is resetted. I think it will read more > > datas from fifo if the read signal is resetted long enough. > > Is there any good design for fifo interface connecting on the > > exteranl bus? > > Using a Synchronous FIFO implies that the read clock and the write > clock are in the same clock domain. Is your MCU supplying the FIFO's > clock or is the FPGA supplying the MCU's clock? If the clock sources > are different, then you either need an Asynchronous FIFO, or you need > to run the MCU and FPGA from the same clock. > HTH > -Dave Pollum It is in different clock, i tried altera's asynchronous FIFO which need two extra clock for reading. is there any better solution?Article: 125919
On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote: > On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: > > > > > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: > > > > i want to read & write data to/from a fifo placed in fpga. MCU's > > > external bus is connected to the chip. I am using the sync-fifo ip of > > > Altera CycloneII. The data bus and control signal are connected to > > > fifo directly. it's unfortune that when i read once from bus, data > > > would be read twice from fifo because there are two clock rising edges > > > during read signal(low active) is resetted. I think it will read more > > > datas from fifo if the read signal is resetted long enough. > > > Is there any good design for fifo interface connecting on the > > > exteranl bus? > > > Using a Synchronous FIFO implies that the read clock and the write > > clock are in the same clock domain. Is your MCU supplying the FIFO's > > clock or is the FPGA supplying the MCU's clock? If the clock sources > > are different, then you either need an Asynchronous FIFO, or you need > > to run the MCU and FPGA from the same clock. > > HTH > > -Dave Pollum > > It is in different clock, i tried altera's asynchronous FIFO which > need two extra clock for reading. > is there any better solution? If your MCU is running much slower than the FPGA, you can use the FPGA's internal clock to run the synchronous FIFO, and a little state logic to generate the necessary (single cycle) pulses for read and write from the MCU interface signals.Article: 125920
Eric Smith wrote: > Now that Microblaze has support for either PLB or OPB, what are the > advantages and disadvantages of PLB? PLB can arbitrate and queue the next transaction address during the current transaction's dataphase. This potentially reduces the dead time between transactions. Also PLB has separate read and write datapaths, which can operate simultaneously in some cases. I don't know if PLB will make your microblaze go faster, but it certainly has potential to make your DMA devices go faster. -JeffArticle: 125921
On Nov 8, 2:25 pm, Maki <prase.ruzica...@gmail.com> wrote: > On Nov 8, 4:56 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Nov 8, 4:08 am, Maki <prase.ruzica...@gmail.com> wrote: > > > > <snip> > > > > > Looking at the tools, it is not clear to me if I can really evaluate > > > > them using ispLever Starter. This package seems to not include the > > > > full set of tools including the simulator and programmer. So I can't > > > > actually program a device with the starter tool, right? Is the > > > > simulator that comes with the ispLever package limited in any way? > > > > The web site does not describe it very well. > > > > No simulator but programmer is there. As for a hardware they offer a > > > cheap parallel and pricey USB programmer. I've used ispLever Starter > > > in several projects IMHO it is a good tool. > > > > Regards, > > > Maki > > > But if there is no simulator, how can you really do anything useful > > with the Starter kit? If you just want to play with the software it > > would be fine, but if you really want to evaluate the package, you > > need to do a small project which requires a simulator, no? I just > > don't have the time to spend playing with tools other than for a > > project of some sort. My customer told me he tried the Lattice parts > > once and had a problem using the tools, so I would want to give them a > > thorough going over and still be prepared to switch to a different > > brand of part if the tools proved wonky. > > In another thread early this year, I was reading that the parallel > > port has gone they way of the dodo bird (at least on laptops) and none > > of the alternate parallel port solutions really work reliably. So I > > want to avoid them at all costs. I'll look at the USB programmer. I > > haven't had a chance to read up on programming the little buggers. Do > > these programmers work through the JTAG port on the parts? > > I use external tool for simulation and an USB programmer. Yes > programmer uses JTAG or slave serial. > > Regards, > Maki It's not free, but the full ispLever software is not expensive and includes branded ModelSim similar to the Xilinx ISE offering. If your starting from Altera tools rather than Xilinx, you may not find the ispLever quite as familiar. Those of us coming from the "X" world can see the common roots of ISE and ispLever from NeoCad. Even the file extensions are (mostly) the same. I have also had issues with ispLever, but I am fairly happy with the 6.1 version, and I understand 7.1 is better, but I haven't upgraded yet. ispLever also includes a choice of Synplify or Precision for synthesis, so if you're comfortable with one of these already you can get a running start. As for the quad flat packs, I would not recommend using them for high-speed designs that may be sensitive to ground bounce. I had trouble with ECP2-6 parts (similar to XP2 but no flash) in the TQ144. The designed used a 7:1 deserializer (Channel Link) and had trouble locking when other unrelated outputs were switching. I got the design to run by using slow slew rate on outputs, but couldn't do everything I wanted with it. I have a new design with the same part in the 256-pin BGA and it is very stable even with a lot of fast switching and two 7:1 deserializers. Since you mentioned PLL's I thought you should be aware of this sort of package issue even if you don't need to run particularly fast. Regards, GaborArticle: 125922
On Nov 8, 8:41 am, maxbatley <max.bat...@gmail.com> wrote: > Hi All, > I've got the Spartan 3E-500 starter kit from Digilent and need to use > the DDR ram on the board. I've searched this group and found lots of > references to a port of the opencores DDR controller, which has been > ported to this board, but after (a lot of) google searching I can't > find anything other than a reference to the fact that it has been done > - does anyone know where I can get hold of the code? > > Many thanks, > Max http://groups.google.com/group/comp.arch.fpga/tree/browse_frm/thread/eac94b9c4bb235a4/7b0c133c9aa5f92f?rnum=1&q=tommy.thorn&_done=%2Fgroup%2Fcomp.arch.fpga%2Fbrowse_frm%2Fthread%2Feac94b9c4bb235a4%2F020c5e6a61e48f63%3Flnk%3Dgst%26q%3Dtommy.thorn%26#doc_020c5e6a61e48f63Article: 125923
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:j811j39ovi79lqns6af52f55bs9fsv0lkp@4ax.com > > Dang, the power supplies are more trouble than the FPGAs. In the FPGA the engineering is already done for you! -- Reply in group, but if emailing add another zero, and remove the last word.Article: 125924
On Nov 7, 10:02 pm, John_H <newsgr...@johnhandwork.com> wrote: > raull...@hotmail.com wrote: > > i would like to ask how can i capture the FPGA master clock signal in > > the oscilloscope? Bcos in the data sheet, it indicates that the master > > clock is located at pin N9 which is not accessible externally. please > > help. thanks a million > > Are you *sure* this signal is not externally accessible? Typically the > BGA package has a matrix of pads and vias. The via for the clock signal > should be exposed on the back of the board, ready for a steady hand to > probe the clock right there "at" the package ball. i am using the XEM3010 board. really have no idea how to tap the signal. please help..
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