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
Thomas Entner wrote: > Hi Karel, > > I cannot comment on Microblaze, but we do this with our ERIC5-processor > (also in S3E 250/500 design). For better performance, we use 1 BRAM as > cache, and the SPI-flash-interface is optimized for sequential accesses. > BTW: The ERIC5 needs much less resources than Microblaze, so maybe you could > get away with a S3E 250 (if every dollar counts ;-). What MHz can you stream from the SPI at, in sequential mode. I see there are now ~70MHz SPI device. I wonder when we'll see DDR SPI devices ? They could do that with another read opcode.. -jgArticle: 96876
<aiiadict@gmail.com> wrote in message news:1139778197.131276.257880@g14g2000cwa.googlegroups.com... > in the schematic capture of Xilinx ISE, there > is ADD symbol button, which will allow you to > pick a component by function, IE : > > AND > NAND > MUX > COUNTER > > > etc... > > I want to be able to pick a symbol by 74xxxx digital > logic series number. > > add symbol > symbol = 7404 > > > etc. > > Is this an available option? > > Rich > You certainly can with Altera Quartus. SlurpArticle: 96877
If Xilinx won't do it, what schematic capture will, and it has to output SCH filetype or other Xilinx compatible schematic format. RichArticle: 96878
Eric, Eric wrote: > I'm trying to enable SMP for a virtex-ii pro board. PPC doesn't > support cache coherency, but that won't be an issue for the > shared memory design I'm going to do. Unless you completely disable the caches, coherency will surely be an issue? JohnArticle: 96879
Hi Wicky Are you researching for a university or a company? Regards R -- ---------------------------------------------- Posted with NewsLeecher v3.5 Beta 3 * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 96880
Daniel - this may well be an option (excellent suggestion - thank you!), and is essentially the same technique as used in some sample-rate converters (for arbitrary up-sample rate ratios). Except in this case the output rate is the same as the input rate, which simplifies the design substantially as a simple linear interpolation between adjacent samples would suffice. I guess the DAC being driven by a clock which has a highly jittery period should be spectrally correct if the data is interpolated in time to the word clock edges which drive it. I will give this more thought over the coming weeks and may even try an inplementation if time allows. Cheers, PeterC.Article: 96881
Has anyone seen a PPC crash while using the I2C drivers. I have a simple EDK project with a PPC that reads and writes to a small flash memory via I2C. In about 1 in 5 million writes the PPC crashes completely. Has anybody else out there seen similiar results? Could the problem be in EDK device drivers for I2C? thanks MattArticle: 96882
>a really stupid question.... so general purpose ports/pins. where are >they on the spartan 3 starter kit? so i read that i can just use the >jtag pins.. but that doesnt seem like many pins to toggle/twiddle. im >used to programming on avr mega 128. where all the ports are obvious. >what i sort of think is that i can use any pins on the board as general >io? are there some pins that are faster ? i just want to connect it to >some DACs. so im thinking ill need at least 20 pins. so i should be >using the expansion slots? If you can't find the schematics on the Xilinx web site, you can get them from: http://www.digilentinc.com/ The main problem I see is that there is only one ground pin on each of the 40 pin connectors. How fast a DAC to you need? Digilent has a board with a (slow) bit serial DAC. -- 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: 96883
Sky wrote: > Guys, > This is a long history. The project doesn't only include the EPLD, but also > many other expensive components. > Unfortunately the change will interest a lot of board already sold. If you've got product in the field and your modifications don't fit into the existing device, there's not a whole lot you can do for those customers, unless you're willing to recall things. > To change the PCB is certainly possible and I believe that this is the best > solution, but it is not acceptable for the marketing. > Someone has advised to look at the Lattice or Actel. products. I will look > for there also. Forget about that; the other vendors' parts won't be pin-compatible, even if they ARE available in the same package. -aArticle: 96884
I am working for Xi'an Flying Science & Technology (www.rtdsp.com), this project is a union of our company and one university of China. Best regards WickyArticle: 96885
Predictor wrote: > rickman wrote: > "This reminds me a bit of the way fuzzy logic was claimed to be such an > advance, but when you looked at it hard you would find little or no > real advantage. Do you see many fuzzy logic projects around anymore?" > > Yes, quite a few. Bruno Di Stefano posted these 10 recently: > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > GPS car navigation from German company NAVIGON comes to USA > (http://msmobiles.com/news.php/4766.html ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Emerson Wins $13 Million Contract to Digitally Automate Korea's > Largest > Coal-Fired Power Plant > (http://www.automation.com/store/pdetails16264.php ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Socket Communications Unveils Industry First Cordless Ring Scanner for > Bluetooth Enabled Mobile Computers > (http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=n... > ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Fujitec eases bottlenecks > (http://news.enquirer.com/apps/pbcs.dll/article?AID=/20060116/BIZ01/60... > ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WCC Announces ELISE for Linux > (http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/stor... > ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Bluetooth "ring scanner" works with Windows Mobile handhelds > (http://www.windowsfordevices.com/news/NS9845751870.html ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Online Marketing: Google Enhances Filters Once Again - How will it > affect you? > (http://rismedia.com/index.php/article/articleview/13227/1/1/) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Handwriting recognizer supports square screens, VGA > (http://www.windowsfordevices.com/news/NS2550969623.html ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > CalliGrapher 8.2 for Mobile Devices > (http://www.digitalhomecanada.com/content/view/1007/60/ ) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > The Weather Wizards > (http://www.avweb.com/news/airman/191492-1.html ) > "With the Forecast Icing Potential (FIP) tool, pilots can make > themselves aware of expected icing hazards along their route up to 12 > hours in advance. FIP provides a high-tech, color, weather map and a > flight-route display of icing potential at flight levels from 3,000 to > 18,000 feet. > The algorithm analyzes weather data from a vertical column perspective. > It determines the cloud top and base heights, checks for embedded cloud > layers, and identifies precipitation types. Once the likely locations > of > clouds and precipitation are found, the physical icing situation is > determined, and a fuzzy logic method is used to determine the icing > potential. Every three hours the model generates forecasts out to 12 > hours. The user can select forecast times from three-, six-, nine-, and > 12-hour intervals to plan safe routes of travel." > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ So that is what, perhaps 1000 to 1 ratio of fuzzy logic projects to hard logic projects? I have never explored fuzzy logic myself, but Bob Pease has and I read what he had discovered about it. There were a lot of claims that were not supported. Of course the lack of evidence of a positive does not prove a negative. But I have seen little reason to consider fuzzy logic a perferable alternative to any other type of design and implementation. Likewise, I don't see any reason to belive that async clocked logic design has significant advantages over standard sync clocked logic design for most applications. There has been a lot of speculation here, a little evidence from vendors was presented (which may or may not have been biased, we don't have sufficient info to judge) and a lot of links of largely irrelevant stuff was given. I stand my my analysis of the logic that was described to me. The main issues are two; async logic is claimed to provide more speed and/or run with lower power consumption. Other than some very unusual applications where it is ok to not meet deadlines and drop data, no one has presented a way that the added speed can be used. Likewise, I have not seen any convincing evidence of lower power than you can achieve using sync designs if your goal is to reduce power consumption. Consider that the example that started all this compared an async processor that is *slower* than the sync processor they are comparing it to. The sync processor also has little designed into it to save power, it just runs full tilt unless you put it in a low power mode directly when you have nothing to do. But this is not the only way to use sync logic. You can be smart about managing clock gating. I think there are other ways to save power in both sync and async designs, but I won't go into that here. I want to explore that myself in an FPGA design I am doing.Article: 96886
PeterC wrote: > Daniel - this may well be an option (excellent suggestion - thank > you!), and is essentially the same technique as used in some > sample-rate converters (for arbitrary up-sample rate ratios). Except in > this case the output rate is the same as the input rate, which > simplifies the design substantially as a simple linear interpolation > between adjacent samples would suffice. > > I guess the DAC being driven by a clock which has a highly jittery > period should be spectrally correct if the data is interpolated in time > to the word clock edges which drive it. > > I will give this more thought over the coming weeks and may even try an > inplementation if time allows. This would depend on the DAC designs - some have quite long settling times, so this might not work too well on those. Plus, you need to know the exact nature of your jitter ? -jgArticle: 96887
Perhaps you can find an earlier version of ISE, say, v5.1, which may, in fact, be the last version that supported functions like that, and the fidelity of reproduction of TTL functions is not 100%, BTW, you can do that with CPLD designs. The TTL components went away in FPGA libraries a release earlier than for CPLD's. The schematic package, ECS, leaves a bit to be desired anyway. It doesn't align components very well, selects components if you click anywhere near them, frequently scrambles your carefully laid-out wires, etc. It also freuquently does stuff you want quite backwards, e.g. numbers signal names in the opposite order from what you told it, but only sometimes, and sometimes requires you to exit the drawing package before it will accept your drawing. A little prune juice, and a lot of whiskey will help a little. RichardArticle: 96888
Hello folks. I would like to let you know that I have made a new release of PacoBlaze (2.0b). Some bugs noticed by users were fixed and the modules were modified a bit to ease implementation, as suggested by a friend. As usual, you can find the files in the 'PacoBlaze' section of my web site, http://bleyer.org/. Wow, it is almost two years since I wrote the first version of PacoBlaze. Thanks for all the people who have found the module and the Java assembler useful (in ways that I never anticipated!) and have sent encouraging words despite the fact that my replies have been terribly slow ;o) My warmest regards. -- PabloBleyerKocik /"How wonderful it is that nobody need wait a single pablo / moment before starting to improve the world." @bleyer.org / -- Anne FrankArticle: 96889
:-) I install new ISE (withh Impact) package from xilinx. Did a simple thing in it and now I,m trying to program my xc9572. I got a parallel cable 3 clone form a company, the cable is autodetected correctly. Now when I tried to get Idcode from my xc9572 it allways fails .... :o( I should have something like this 00001001010100000100000010010011 but I got strange thing sometime only 000000... sometime stuff like that 00001010010101000001000010010011 00001010010101000000000010010011 00000101001010100010000010010011 I tried to put HIHGZ option on but still failed ... I'm in the fog !! Is someone able to program with a cable3 and the latest Xilinx ISE service pack ?Article: 96890
rickman wrote:
> So that is what, perhaps 1000 to 1 ratio of fuzzy logic projects to
> hard logic projects?
Absolutely a BS logical deduction. By that same reasoning, air planes
are totally useless because they are not used as frequently as bicyles,
motorcycles, and cars. That earth movers and excavators are useless
because their are not as many of those as there are shovels, power
drills or screwdrivers. That ocean going oil tankers are not useful
because they are a minority in oil transportation designs compared to
rail tankers and semi-tankers.
If it's the right tool, device, design ... use it ... even if
relatively rare in use globally.
The experts basically agree that Fuzzy logic, especially when used for
control systems, is a different mathmatical frame work for representing
probabliity based inputs into a system, and that it takes some pretty
serious math to prove that the resulting system is stable -- not unlike
a traditional control system design which has probability based control
functions and inputs which are not continuous. There are also a number
of trivial FL designs, which clearly can be implemented other ways, and
in many cases probably should be for real world applications. There are
also designs where traditional mathmatical models of the system simply
are not practical to develop, where researchers find that FL systems
combined with other AI approaches yeild usable solutions, which may or
may not be as optimal as if you spent the time to actually discover a
more formal description of the problem (if at all possible) and use
traditional approaches.
> I have never explored fuzzy logic myself, but Bob Pease has and I read
> what he had discovered about it. There were a lot of claims that were
> not supported. Of course the lack of evidence of a positive does not
> prove a negative. But I have seen little reason to consider fuzzy
> logic a perferable alternative to any other type of design and
> implementation.
I also read that series a couple years ago, and the nut of it was that
he insulted a lot of people and expected them then to argue with him to
debate the merits of the technology, and when they didn't used that as
proof in the final article that he was right.
> Likewise, I don't see any reason to belive that async clocked logic
> design has significant advantages over standard sync clocked logic
> design for most applications.
Which may well be partially true today, given the lack of tools and
huge bias left over from 25 years of teaching people that async is bad.
I did my VLSI class 20+ years ago using Carver Mead and Lynn Conway's
book which also discussed async designs with the instructor absolutely
bashing async design, as probably a few hundred thousand other students
have been subjected to the sync only mantra. I did a self clocked high
speed data separator for my project, which didn't go over well, but was
also impossible as a clocked design for the techology of the day.
But you seem to argue more than just the point of fuzzy or async being
unreasonable for many projects, you seem to also argue that they aren't
reasonable for ANY project. Frequenty by dismissing the results of
actual projects with conjecture that you somehow could do the same with
sync design. And that really is asserting that you some how know
better than those other researchers and engineers, even when you also
state you do not have experience designing with these technologies.
> The main issues are two; async logic is claimed to provide more speed
> and/or run with lower power consumption. Other than some very unusual
> applications where it is ok to not meet deadlines and drop data, no one
> has presented a way that the added speed can be used. Likewise, I have
> not seen any convincing evidence of lower power than you can achieve
> using sync designs if your goal is to reduce power consumption.
BS.
You were given references which directly refute this ... which if you
actually read, you are then implicitly claiming those references are
somehow fraudulent, or otherwise incorrect, without providing proof in
your unfounded claim above. If you did not read, and analyze, then you
do not have the right to make this claim before doing so, and
sucessfully refuting their work.
You were provided references for the arm project, which clearly state
the operating power of the async design was 1/3 that of the clocked
reference design in units of W/MHz, which you promptly ignore because
the resulting target design was slower. This IS a valid measurement
when power scales linearly with clock rate.
You were provided references, and more are available, where PL async
tools where applied to existing sync designs, and significant power
reduction resulted.
> Consider that the example that started all this compared an async
> processor that is *slower* than the sync processor they are comparing
> it to.
The sync reference design was the ARM968E-S described as "Smallest,
lowest power ARM9E Family CPU to date (gate count = 80% of ARM966E-S)"
by the developers, who obviously are very proud that they got the size
and power down again on this iteration of their product. You are
effectively stating that you can take their optimized sync design, and
reduce it's power per megahertz by 65+% as the folks at Handshake
Solutions did -- which implies that you consider the ARM.com team that
did the ARM968E-S core design pretty close to clueless and incompetent
NO? I would guess that the ARM.com team is far from incompetent when it
comes to optimizing their design.
http://www.arm.com/products/CPUs/ARM968E-S.html
The handshake solutions team then takes that netlist, and applies async
design tools to it, and manages to reduce it's power significantly ...
http://www.handshakesolutions.com/Products_Services/ARM996HS/Index.html
>From 130nW/MHz to 45nW/MHz ... a 65+% reduction in power. Which you
then dismiss with "Likewise, I have not seen any convincing evidence of
lower power than you can achieve using sync designs if your goal is to
reduce power consumption."
It seems, that you refuse to accept the evidence, and refuse to refute
it, offering only the assertion that you can do better, and fail to
even justify that with proof.
Article: 96891fpga_t...@yahoo.com wrote: >From 130nW/MHz to 45nW/MHz ... a 65+% reduction in power. Which you ops ... 130uW/MHz to 45uW/Mhz ...Article: 96892
Hi Rich, in the older Webpacks (ISE 4.2, maybe even 5.x) was a small TTL library available for CPLDs only. Maybe you can access it by the ISE-Classic programms if you have no acess to the older Webpacks. It surely can be converted to FPGAs. But do you really need it? The symbol INV is an Inverter , is called an inverter, and is the only single Inverter. Why use multiple names for the same thing (e.g. 74xx04, 74xx05,74xx14, 74xx4049). All Inverters, some with special features that may be unused inside a programmable chip. Why drawing more than nessecary? AND2b1 and its companions gives you inverted inputs without pushing symbols around. INV4 etc. work on whole busses without need to name every line. The MSI functions don't have all the excessive I/Os that are often unused or abused for "tricks". Designing with the pure functions gives you better results. Some old chips can hardly be reimplemented in CPLDs or FPGAs. Look for 74ls193 in the forums. Time is better spent on rethinking the old design, or even learn a HDL than reimplementing libraries for obsolete components. From your former post I know that you would prefer to do nearly nothing to reimplement your old TTL schematic into actual devices (OSR :-) ) but be sure, it won't work that way. Every beginners pitfall is waiting for you. (multiple and gated clocks, asynchronous and gate delay designs and many more) have a nice synthesis EilertArticle: 96893
fpga_toys@yahoo.com wrote: > The handshake solutions team then takes that netlist, and applies async > design tools to it, and manages to reduce it's power significantly ... hmmm ... need to slow down ... it was not stated they started with this netlist, just that they have an equiv design.Article: 96894
that was really simple!!!! thanks, PeterArticle: 96895
Oops, I hit the wrong button somewhere, here for the newsgroup: >>> I cannot comment on Microblaze, but we do this with our ERIC5-processor >>> (also in S3E 250/500 design). For better performance, we use 1 BRAM as >>> cache, and the SPI-flash-interface is optimized for sequential accesses. >>> BTW: The ERIC5 needs much less resources than Microblaze, so maybe you >>> could get away with a S3E 250 (if every dollar counts ;-). >> >> >> What MHz can you stream from the SPI at, in sequential mode. >> I see there are now ~70MHz SPI device. >> >> I wonder when we'll see DDR SPI devices ? >> They could do that with another read opcode.. >> >> -jg >> > > I used 40 MHz in that project, I know of 50MHz devices, I think I have to > take a second look for the 70MHz ones ;-) The ERIC5 architecture has short > opcodes of 8 or 9 bits, this helps of course. The 70Mhz one I spotted was here, at 8MBits. I think ST mentioned 66MHz http://www.atmel.com/dyn/products/datasheets.asp?family_id=616 > However, a change of flow always has a huge penalty because the complete > address (+ the dummy-byte for fast read-out) has to be transmitted. Of course, but that could change the core design a little, or even the SW Tools (or mindset) for creating the Code. After all, with Serial Flash, the Code becomes dirt cheap, so you trade off compactness, for blocks that fit the cache. At 70MHz, you get close to 9MBytes/s of (linear) BUS bandwidth, which is pretty good. Quite a few 8 bit uC are around there... On present trends, that speed could increase a little more - it is not quite at FLASH access ceiling yet. The smart thing to do, would be to (optionally) flip the HOLD pin, so it can pause the FPGA streaming, on page boundaries - that would get much more MHz out of the system regards Jim G.Article: 96896
"Hal Murray" <hmurray@suespammers.org> wrote in message news:JeGdnSqemJlMmW3eRVn-uw@megapath.net... > > The main problem I see is that there is only one ground pin > on each of the 40 pin connectors. > Hi Hal, An SI work-around for driving long ribbon cables is to drive every other pin low. Bummer if you need all the I/O! Cheers, Syms.Article: 96897
On Mon, 13 Feb 2006 10:08:59 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >"Hal Murray" <hmurray@suespammers.org> wrote in message >news:JeGdnSqemJlMmW3eRVn-uw@megapath.net... >> >> The main problem I see is that there is only one ground pin >> on each of the 40 pin connectors. >> >Hi Hal, >An SI work-around for driving long ribbon cables is to drive every other pin >low. Bummer if you need all the I/O! >Cheers, Syms. > Here's another way : The ground is the nearest to the solder side of the inner planes so it's possible to dremel down to it & add more grounds.. http://www.redremote.co.uk/electricstuff/ektapr61.jpgArticle: 96898
"Mike Harrison" <mike@whitewing.co.uk> wrote in message news:tin0v1hh1b8c01eoi9tif20elqsh3treio@4ax.com... > > Here's another way : > The ground is the nearest to the solder side of the inner planes so it's > possible to dremel down to > it & add more grounds.. > http://www.redremote.co.uk/electricstuff/ektapr61.jpg > Mike, You butcher! VG! I wonder if there's a lesson here for the prototype board product guys. After all, these boards are often bodged up for proof-of-concept projects. Put a ring of exposed ground all the way around the edge of the board to help SI design. Carefully stiched to the gnd plane, of course. What about it, Mr. Adair? Cheers, Syms.Article: 96899
:-) wrote: > :-) > > I install new ISE (withh Impact) package from xilinx. > Did a simple thing in it and now I,m trying to program my > xc9572. > > I got a parallel cable 3 clone form a company, > the cable is autodetected correctly. > > Now when I tried to get Idcode from my xc9572 it allways fails .... :o( > > I should have something like this > 00001001010100000100000010010011 > > but I got strange thing > sometime only 000000... > > sometime stuff like that > 00001010010101000001000010010011 > 00001010010101000000000010010011 > 00000101001010100010000010010011 > > I tried to put HIHGZ option on but still failed ... > > I'm in the fog !! > Is someone able to program with a cable3 and the latest Xilinx ISE > service pack ? I have had the same problem. Once you get to the Impact window and the cable is detected, go to Output ->cable setup A dialog box will appear and there is a drop down box for the cable speed, which defaults to 5MHz. This will not always work (depending on the wiring of the target). Play with the slower speed settings and you'll probably fix your problem. One of my designs requires the download speed to be 200kHz It's also possible the drop down will say 'Auto' (this seems to depend on whether thinsg have been previously set up) - select 'manual' and a new dialog will appear where you can select the speed. Cheers PeteS
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