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
Goran Bilski wrote: > > There should only be different 3 numbers used as sizes, > 0, 1 or infinity. Any other number will creating barriers > that will be reach and have impacts on the system. I'm headed over to payroll right now! EricArticle: 69776
Hi, I have no idea what it costs, the students were able to make use of the downloadable demo version, and they were even offered technical support when they ran into trouble... Eric "E.S." wrote: > > Eric Crabill wrote: > > > Hi, > > > > There's a tool called Universal Scan that does just what > > you are looking for. http://www.universalscan.com/ > > I had some students using it at SJSU to program an Intel > > Flash attached to a Spartan-IIE. I was impressed with > > the tool. > > In the last issue of Xcell-Journal (49) there is an article > about it. They call it "inexpensive" ;-)Article: 69777
kempaj@yahoo.com (Jesse Kempa) writes: > "Subroto Datta" <sdatta@altera.com> wrote in message news:<n4zqc.524$1O4.119@newssvr15.news.prodigy.com>... > > Vadim, make sure that you have the Unused Pins for your Quartus project set > > to be Inputs Tristated. You can do this as follows after the project is > > opened in Quartus: > > > > 1. Click on Assign Device > > 2. Click on the Device and Pin Options Button > > 3. Click on the Unused Pins Tab. > > 4. This should be the first Radio button. > > > > Hope this helps. > > > > - Subroto Datta > > Altera Corp. > > > Just to elaborate on why this is: > > A feature of the Nios development boards is to demonstrate remote > reconfiguration. This is done via an FPGA I/O which is connected to > the MAX CPLD on the board. The MAX CPLD is programmed to re-configure > the FPGA when the signal is driven low (in this way, the FPGA can send > a signal telling the MAX chip to reconfigure itself). For reference > designs that include this pin and leave it high, or tri-stated, there > is no issue. However, a user design must either drive this pin high > manually, tri-state the pin manually, or leave the pin un-assigned and I informed Vadim about reconfigure issue a few weeks ago in: http://groups.google.com/groups?safe=images&ie=UTF-8&as_ugroup=sci.electronics.cad&as_umsgid=m3brlbcge1.fsf@scimul.dolphinics.no&lr=&hl=en Maybe there's another problem? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 69778
In article <40ABC160.8B7D3197@xilinx.com>, Eric Crabill <eric.crabill@xilinx.com> wrote: >Goran Bilski wrote: >> There should only be different 3 numbers used as sizes, >> 0, 1 or infinity. Any other number will creating barriers >> that will be reach and have impacts on the system. > >I'm headed over to payroll right now! Sorry, Cisco has decided to switch back to 100% ASIC, your payroll is now set to size 0. :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 69779
Jon Beniston wrote: <snip> > > Fair play to them, I didn't really think too much of NIOS, but if they > really can push 200MHz with this, then I am impressed. I think I spotted the words 'simulated' close to that number... :) ie the standard 'release it today, but talk about how fast it will be next year....' -jgArticle: 69780
Eric Crabill wrote: > Goran Bilski wrote: > >>There should only be different 3 numbers used as sizes, >>0, 1 or infinity. Any other number will creating barriers >>that will be reach and have impacts on the system. > > > I'm headed over to payroll right now! No, No, stooop ! They'll choose the ONE in the middle!! :)Article: 69781
Goran Bilski wrote: > It's creating weird situation in embedding processing where you reach > the limit of the window. > There should only be different 3 numbers used as sizes, 0, 1 or infinity. > Any other number will creating barriers that will be reach and have > impacts on the system. > On reaching the limit of the register window, you have a big chunk of > data to save and load which isn't nice to have when you need to have a > deterministic system. I'm lost - since the register count is finite at around 32 in most RISC designs, how does removing a feature improve the situation ?. I don't know the specific NIOS details, but Register window/Frame Pointer/Register Bank select schemes have been around for years, and can greatly help code density and reaction speed if done properly. I think sparc had a clever partial frame pointer, that allowed some registers to carry calling/return parameters, and some as local variables. The compiler needs 'to be on its toes', but that's a SW housekeeping issue. Another nice feature of register frame pointers, is if you are uncomfortable with them, you can just ignore it, and you have a 'vanilla RISC' core. -jgArticle: 69782
Tim, Low blow. S3 shipped a lot of parts last quarter. A whole lot of parts. No one expected the product to gather that many orders that fast. Even the optomists among us were made to look like pessimistic fools. If we would have only believed our own sales pitch that S3 was a better deal than an ASIC in volume (which it is), we might have been at least partially prepared. Austin Tim wrote: > "Austin Lesea" wrote > > >>At lunch the other day we were reminiscing about how the Z8000 never >>took off because they changed their architecture and instruction set >>completely from the Z80 and immediately alienated all of their customers >>(who were still programming in assembly language in those days). > > > Not quite getting it into production may have troubled some customers... > > >>Not like that anymore. > > > The Spartan-3 of its day ;-) > >Article: 69783
rickman wrote: > Jim Granville wrote: > >>Jim Granville wrote: >><snip> >> >>> There are a LOT of Arm cores comming as MCU, with on chip FLASH, and >>>that solves the smaller-memory end, by removing the memory BUS layout >>>problems. >>> >>> Look at Philips LPC2xxx, STm STR7xxx, Analog Devices ADuC7xxx, TIs >>>TMS470, Sony, etc for FLASH+ARM offerings, many with external memory >>>interfaces. >> >>.. I should have included Motorola's MAC7100 ARM devices, TQFP144, >>512KF, 32KR, Automotive specs.. > > > Wow! This is a part I have been looking for for quite sometime. I > don't see any info on pricing or availability... any idea? Nope, but when I saw 5V and Automotive I did think of you :) The date tags on the info gives some idea - looks 'real' to me. I'd guess it's like the TMS470, targeted to the Automotive sector in the truest sense of the term. (ie helps if you're called Ford, GM, BMW.. ) - but I'm sure both TI and Motorola are seeing customers in the 'tough industrial' sectors who would like these devices too.. -jgArticle: 69784
"E.S." <emu@ecubics.com> wrote in message news:<C9vqc.149$Ou.77@fe39.usenetserver.com>...
> > The VGA timing interface will have a couple or three counters.
> >
> > As you can instantly tell, it hasn't been thought through yet. This
> > is day two of my "do something concrete" plan.
>
> Have a look at www.fpgacpu.org. Jan Gray put a 16bit
> RISC,DMA,MemoryControl & Video in a chip which is so small, it isn't
> even supported by xilix tools anymore ;-)
That's very interesting. His VGA timing block uses half as many
registers as my first go at it. I think I'm over-using registers
(where wires would work fine).
Jan uses an LSFR counter for his horizontal and vertical counters. I
read a thread on this newgroup about such counters from, I think,
around 2001. Talking about wide 100MHz counters. The general view
was that LFSR counters use fewer CLBs than binary counters, and run
faster due to the lack of a carry chain, but come with caveats. A
post near the end of the thread said, effectively, "use straight
binary counters and let the synthesis tool figure it out - modern
FPGAs are fast and the tools are good".
The VGA dot clock is around 25MHz. I need a 10-bit horizontal counter
and a 9-bit vertical counter.
reg [9:0] xcnt; // counts from 0 to 799.
always @(posedge clk)
if (reset || xcnt == 799)
xcnt <= #`TP 10'h0;
else
xcnt <= #`TP xcnt + 1;
Is that sufficient for a 10-bit 25MHz counter in the real world for
this application, or should I already been looking at LFSR counters?
> Just start with your design, and look the place & route statistics.
> Then you really get a feeling what resources you use on what function,
> and probably you even notice, that you implement it in a not so
> efficient way for an FPGA.
>
> And as soon you have some solid design,
> you still can run the place & route on different families & chips,
> then you really see what the difference is.
Thanks. That sounds like a plan.
Paul.
Article: 69785> Each has their own uses... > Europe fought for 30 years to determine which should prevail: > > Catolicism *OR* Protestantism. > > Guess what .... > What? You're saying both ZigBee and Bluetooth are a waste of time? Cheers, JonBArticle: 69786
I'm having problems getting a system running with a Memec 2VP4LC board. I use Base System Builder, following Xilinx EDK 6.2 tutorial instructions, specifying a Memec Virtex-II Pro P4-FG456 board and making the appropriate changes to the UCF file. The whole process runs fine and the FPGA programs fine but seems inert. Memec's Ultracontroller demo runs OK so the board is probably OK. Has anyone had luck with this board? Thanks. -DaveArticle: 69787
Using LFSRs for video counters comes from the days when 25-30 MHz performance took a lot of
work, and especially with earlier families like the 3000 and 3100 that did not have carry
chains (in which case, a binary counter not only was slow, but it also took up a lot of
resources...more than one level of logic). 10 bit counters in modern FPGAs can run at
several hundred MHz, and the carry logic is free. For 25 MHz video, it is not worth the
extra headache of working with an LFSR. It gains you nothing in this case. If you look at
my Dynamic VIdeo hardware paper from ca. 1996, it also used LFSRs in the video timing logic.
That was done in National CLAY FPGAs, which are structurally similar to the Atmel 6000 series
parts, no carry chain, very limited interconnect, and simple logic cells that did not do
random logic well.
Paul Marciano wrote:
<snip>
>
> reg [9:0] xcnt; // counts from 0 to 799.
>
> always @(posedge clk)
> if (reset || xcnt == 799)
> xcnt <= #`TP 10'h0;
> else
> xcnt <= #`TP xcnt + 1;
>
> Is that sufficient for a 10-bit 25MHz counter in the real world for
> this application, or should I already been looking at LFSR counters?
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69788
Hopefully the size of your paycheck will be the third possible
size, not the first ;-)
Eric Crabill wrote:
> Goran Bilski wrote:
> >
> > There should only be different 3 numbers used as sizes,
> > 0, 1 or infinity. Any other number will creating barriers
> > that will be reach and have impacts on the system.
>
> I'm headed over to payroll right now!
>
> Eric
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin,
1759
Article: 69789"Ray Andraka" <ray@andraka.com> wrote in message news:40AB48D9.C3F88E92@andraka.com... > If you are doing a synchronous design you normally shouldn't run out of clock > resources. What are you doing that uses so many clocks? I suspect your > clocking is also causing your routing woes. The virtex parts have abundant > routing resources; it is not that easy to use them up. Some assumptions in there Ray : "...If you are doing a synchronous design ..." but these days people are doing SOC designs that might have a video clock, a CPU clock, a clock driving an ethernet PHY, and a perhaps some refresh logic for their DRAM controller. I'm not disagreeing with you, my point was that "gates" are generally not the thing you run out of first. Next up "...The virtex parts..." however the original poster wanted to stay away from the "expensive" chips. so starting from CPLDs and moving up, you're somewhat constrained there. Lots of clock resources in a Virtex II Pro, but then again in single quantities the chip is $300. :-) --ChuckArticle: 69790
Even the smallest FPGAs have four or more clock nets, and that is going back to
the
4000's. Clock enables can do a lot for you, in most cases there is not really
a need for
a proliferation of clocks. Multiple clock domains give rise to potential
timing
constraints issues, as well as problems crossing clock domain boundaries. Not
that
any of that is insurmountable, just that it requires extra diligence to make
sure you
do it right, and that the tools don't mess up your good work.
When I said virtex parts, I was referring to the virtex architecture, which
includes all the
current families. SpartanII is the virtex1 architecture, spartan2e is virtexE,
spartan3 is
a mutation of virtexII. The point is all of these families have ample
routing. Now,
whether the tools make efficient use of that routing is another question
altogether (they
don't, the tools now do a 'lazy' routing that only improves the routing until
it is good
enough. Problem is in a dense design, the circuitous routing artificially
congests the
routing resources which can make it appear that you do not have the routing to
make timing.
Poor placement can also aggravate the routing. The placer is *still* very bad
at placing
logic when a signal goes through multiple LUTs between flip-flops, often
placing the LUTs
without flip-flops far from the destinations, and well out of the way between
the source and
destination. The result is again unnecessary congestion of the routing
resources, and pathetic
timing results. Floorplanning will relieve enough of the problems caused by
the placer that
it is very hard to run out of routing.
BTW, the routing is generally more stressed with larger devices rather than the
smaller ones.
Required routing goes up roughly with the square of the number of LUTs, yet the
routing
network is virtually unchanged across the family. Additionally, placement is
more critical with
larger devices because haphazard placement will incur large routing delay
penalties, and that
makes the job of the router tht much harder (possibly leading to a no-route
situation due to timing)
With small FPGAs, it is the memories followed by logic that gets used up
first. I would argue
that the routing in the cheap FPGAs is even more abundant.
CPLDs are a different animal altogether. There, the routing between macrocells
is generally
sparse, and without careful planning it can be easy to use up the routing
there.
I stand by my earlier comments.
Chuck McManis wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40AB48D9.C3F88E92@andraka.com...
> > If you are doing a synchronous design you normally shouldn't run out of
> clock
> > resources. What are you doing that uses so many clocks? I suspect your
> > clocking is also causing your routing woes. The virtex parts have
> abundant
> > routing resources; it is not that easy to use them up.
>
> Some assumptions in there Ray :
>
> "...If you are doing a synchronous design ..." but these days people are
> doing SOC designs that might have a video clock, a CPU clock, a clock
> driving an ethernet PHY, and a perhaps some refresh logic for their DRAM
> controller. I'm not disagreeing with you, my point was that "gates" are
> generally not the thing you run out of first.
>
> Next up "...The virtex parts..." however the original poster wanted to stay
> away from the "expensive" chips. so starting from CPLDs and moving up,
> you're somewhat constrained there. Lots of clock resources in a Virtex II
> Pro, but then again in single quantities the chip is $300. :-)
>
> --Chuck
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69791On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com> wrote: >Sean, > >Brute force! > >As long as the locked signal is low, periodically reset the DCM, and see >if the locked signal remains low. > >It takes a little state machine, and it would have to run off the DCM >CLKIN (which is OK, just assume it is running at 25 MHz to calculate how >many counts you need to wait to make sure that LOCKED has gone high). > >Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, >use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset >the DCM). > >(pseudo code below) > >while CLKIN_STOPPED = 1 (clock is running) > > assert (reset for one clock) > wait XX uSec > > check DCM: DCM not operating? (check approp. status) > assert reset (for one clock) > wait XX uSec > else do nothing > > wait XX uSec (use one counter for all waits) > > go to check DCM Hi Austin, Is there any fundamental reason why this logic couldn't be built into the DCM and be enabled/disabled by a config bit? The "wait XX usec" might be a problem, but this could by worked around in a number of ways (e.g. by using psclk as a timing reference, etc.) I find that having to add this state machine to all DCMs just to get them to work reliably is a bit of a pain. Regards, Allan.Article: 69792
Vadim acknowledged that setting the Unused Pins to be Iputs tristated solved his problem. - Subroto "Petter Gustad" <newsmailcomp6@gustad.com> wrote in message news:87isescgh0.fsf@filestore.home.gustad.com... > > Maybe there's another problem? > > Petter >Article: 69793
Hello friends, I am new to working with Xilinx tools. I have a verilog design and its pre-synthesis similation is tested. Now to verify the design, I have synthesized it using Xilinx ISE tool (using XST) to get .ngd file. a verilog netlist is generated from .ngd using ngd2ver command. I think the generated netlist uses the simprims library. i simulated (using ModelSim) the netlist using the same testbench as i used before. vsim -L simprims_ver simprims_ver.glbl mytopdesign But one of the signal is different. an output signal 'a_recieved' should be high for 1 clock cycle and go down, but it is high for 2 clock cycles. i didn't know any way to debug as the names of internal wires generated are completely different. could anyone please tell if i am doing correctly and help me in debugging? thanks kumarArticle: 69794
Hi jamie, I am already using the DPLL, but by using the DPll how will it reduce the PAD delay.I want the PAD delays to be less. rgds, prav "Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message news:<c8djnn$6jb$1@zcars0v6.ca.nortel.com>... > If you aren't already using a DLL, you might consider it. It can remove > several nanoseconds of clock-to-output delay. These are available in the > device you're using. > > Increasing drive strength can cause problems with simultaneous switching > such as ground bounce. Xilinx's documentation should have guidelines telling > you how many drivers of each strength you can use within a bank before > having problems, but these are only guidelines. > > "prav" <praveenkn123@yahoo.com> wrote in message > news:863df22b.0405180416.23b4ec7e@posting.google.com... > > Hi all, > > > > I am targeting my design to XCS200 -5 fg256(SPARTAN device) . My > > OFFSET OUT timing constraints are very tight.So inorder to decrease > > the PAD delay i am forced to set the drive strength to 24 and > > SLEW=FAST. only 2 pins of the 137 I/O's which i am using have a drive > > strength of 24 rest of them have a DRIVE=12. > > > > Can anyone tell me what is the significance of this DRIVE strength in > > REAL time.Will it create any problems having a DRIVE=24 in real > > time??. > > > > Thanks n rgds, > > pravArticle: 69795
Dave wrote: > I'm having problems getting a system running with a Memec 2VP4LC > board. I use Base System Builder, following Xilinx EDK 6.2 tutorial > instructions, specifying a Memec Virtex-II Pro P4-FG456 board and > making the appropriate changes to the UCF file. The whole process > runs fine and the FPGA programs fine but seems inert. Memec's > Ultracontroller demo runs OK so the board is probably OK. > > Has anyone had luck with this board? I don't know this board, but a common problem when the program doesn't start is the wrong reset level. Maybe the tutorial uses active high reset, but the board generates active low, so the FPGA stays in reset all the time. cu, SeanArticle: 69796
Dear All, I would like to ask you some timing questions. First scenatio and first question: I have two signals, for example, /CS and /RD. Looking at the device datasheet it says that: -tCLRL CS LOW to RD LOW 0 ns -tRHCH RD HIGH to CS HIGH Intel mode 0ns Then looking at the datasheet I must assert /CS before /RD and de-assert /CS after /RD. I would like to know if it is possible to Assert /CS and /RD in the same clock cycle or should I first assert /CS in a clock cycle and in the next clock cycle assert /RD. I mean, in my state machine would be ok to assert /CS and /RD in the same cycle due to "0ns" of the tCLRL and tRHCH or should I use two clock cycles?. And second scenario and question: RULE 2.58: During read cycles, the responding SLAVE MUST release all of D00-D31 before releasing DTACK* or BERR* to high. In a Read Data cycle in an VME Slave when the slave places the data and asserts the signal /DTACK, waits until detects that /DS is high again (Master). Then must release the data bus and rise (de-assert) /DTACK at least "0ns" after releasing the data bus. Could I release the Data bus and de-assert /DTACK in the same clock cycle or should I release the data bus in a clock cycle and de-assert /DTACK in the next clock cycle?. Thanks a lot and best regards, JaviArticle: 69797
>Then looking at the datasheet I must assert /CS before /RD and >de-assert /CS after /RD. I would like to know if it is possible to >Assert /CS and /RD in the same clock cycle or should I first assert >/CS in a clock cycle and in the next clock cycle assert /RD. I mean, >in my state machine would be ok to assert /CS and /RD in the same >cycle due to "0ns" of the tCLRL and tRHCH or should I use two clock >cycles?. What are your priorities? "0ns" means one signal has to happen before or at the same time as the other. If you change two signals on the same clock edge, you don't know which one of them might change first. So you need to do something to make sure the one you want changes first. A clock cycle is the simple and clean way to do that. It costs a cycle. Can you afford that? If so, end of problem. If you don't want to burn a whole cycle, then you start looking for tricks. You can sometimes use the other edge of the clock. Now it only costs you a half-cycle. Or use a much faster clock where the state machine counts several clocks for each of the old states. Add some routing delay on the PCB (6 inches per ns). Clock one signal in an IOB and the other one in a CLB near the IOB so it takes a little longer to get out there. Use lower drive on one signal. (This assumes the loading and layout are matched.) [Don't forget to check the other edge too.] -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 69798
>This doesn't explicitly clock out SO on the falling edge, however SO should >have the correct value on the rising edge of a parallel clock right? Since >the propagation delay of the clocking in the new data is non-zero, is it >reasonable to assume that S0 will have the correct data on the rising edge? The rules of the game are that you have to meet both setup and hold times. If you have a string of FFs like a shift register, you are depending on the clock-out delay of the source FF to cover the hold time of the target FF. You also have to leave room for clock skew. If the manufacturer promises that things like that will work in their silicon, the tools don't have to bother checking for hold times. Xilinx works that way. I assume others do, but I'm not familiar with the details. When you go between chips, you can't ignore hold time anymore. You have to check them just like you check the setup times. The case you describe will probably work, but it's possible to make things like that fail. Clock skew is probably the easiest way. The classic clock problem with (really) old CMOS logic was a clock feeding a long string of DIPs. The capacitive load of the clock pins turns the clock trace into a loaded transmission line which is quite a bit slower than the speed of light. Unloaded data bits could beat the clock and cause hold problems. Or the input thresholds could be slightly different on a slowly rising clock so one chip of an adjacent pair clocks ahead of its neighbor. Using the other edge of the clock avoids all that nonsense. It gives you a half cycle of setup and a half cycle of hold. It will work with horrible clock skew between chips. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 69799
jon@beniston.com (Jon Beniston) writes: > > > Possibly not the same problem, but I've seen issues recently with a > > > Core Gen RAM not being synthed properly by XST. I switched over to > > > Synplify and the problem disappeared.. My faith in XST is limited! > > > > > > > I didn't think that Coregen'ed stuff *was* synthesised - does the > > synth not see it as a black box? Then the downstream tools find the > > EDIF netlist to fill in the gap.. > > Could it wire up the black box wrong? Functional sim worked okay and > post-translate sim didn't (neither did h/w). It could have been the > translate prog that screwed up I guess, but I didn't have the time or > will to find out. That sounds more likely - or the synthesis of something else related to the RAM (like a WE or address counter for example) > Whenever things like that have happened before, > switching to Synplify always fixed it. > It's not bug-free either.... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt
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