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
Ray Andraka <ray@andraka.com> wrote: > Hamish, be careful with that. 4.2 has a bug where designs with large ncds gets a > memory conflict under win2K. We made that mistake, and had to run under NT4 in > order to continue on with the design. That 2v6000 design gets through map in an > hour and 40 minutes on an old 800 MHz P3 with 1GB (paging like crazy) under 4.2i > on NT, won't run on 4.2i under win2K, and takes over 25 hrs under 5.1 running on a > 2GHz K7 with 2GB memory . Ouch. What was the % utilisation of the 2V6000? The biggest I've done is 50-60% and map and par times and memory usage haven't been unreasonable. We've had some regular BITGEN crashes on NT which haven't happened on 2000. Occasionally a PAR crash too. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 48151
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > hamish@cloud.net.au wrote: > : Still waiting for v5.1 to arrive. Upgrading all machines to Win2000 in > : anticipation. > > For a start, use the free downloadable Webpack, which is based on 5.1. Does it do 2V6000s? I'd guess not! Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 48152
Barry Brown <barry_brown@agilent.com> wrote: > signal Logic0 : std_logic := '0'; > signal Logic1 : std_logic := '1'; These initial values are used if you don't drive the signals elsewhere. > bram: RAMB4_S4_S4 port map ( > ADDRA => ReadAddr, > ADDRB => WriteAddr, > DIB => WriteData(4*i+3 downto 4*i), > DIA => Logic0Bus, > WEA => Logic0, > WEB => WriteEnable, > CLKA => Clock, > CLKB => Clock, > RSTA => Logic0, > RSTB => Logic0, > ENA => Logic1, > ENB => Logic1, > DOA => ReadData(4*i+3 downto 4*i), > DOB => open > ); > end generate bram_gen; You can map directly to '0' and '1' and avoid the need for Logic0 and Logic1 signals. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 48153
The whole thing compiles in about 6 hours on an 800 MHz P3 with 1GB memory with lots of
paging under 4.2i with NT. Gets a memory conflict under win2K while reading the .ncd,
which is just over 100MB. With 5.1sp1, it complestes map over 25 hours into the compile
on a 2GHz P4 with 2GB memory, independent of OS. We still do alot of virtex (QPRO),
spartanII and virtexE designs, for which we use 3.3sp8 because it does better. Haven't
really seen PAR and bitgen problems there. Here's the design summary from map under the
NT machine:
Design Summary
--------------
Number of errors: 0
Number of warnings: 18390
Number of Slices: 26,854 out of 33,792 79%
Number of Slices containing
unrelated logic: 0 out of 26,854 0%
Number of Slice Flip Flops: 46,882 out of 67,584 69%
Total Number 4 input LUTs: 34,907 out of 67,584 51%
Number used as LUTs: 30,327
Number used as a route-thru: 32
Number used for Dual Port RAMs: 1,334
(Two LUTs used per Dual Port RAM)
Number used as Shift registers: 3,214
Number of bonded IOBs: 779 out of 824 94%
IOB Flip Flops: 1,601
Number of Tbufs: 278 out of 16,896 1%
Number of Block RAMs: 75 out of 144 52%
Number of MULT18X18s: 50 out of 144 34%
Number of GCLKs: 6 out of 16 37%
Number of Startups: 1 out of 1 100%
Number of Captures: 1 out of 1 100%
Number of RPM macros: 88
Total equivalent gate count for design: 6,224,453
hamish@cloud.net.au wrote:
> Ray Andraka <ray@andraka.com> wrote:
> > Hamish, be careful with that. 4.2 has a bug where designs with large ncds gets a
> > memory conflict under win2K. We made that mistake, and had to run under NT4 in
> > order to continue on with the design. That 2v6000 design gets through map in an
> > hour and 40 minutes on an old 800 MHz P3 with 1GB (paging like crazy) under 4.2i
> > on NT, won't run on 4.2i under win2K, and takes over 25 hrs under 5.1 running on a
> > 2GHz K7 with 2GB memory .
>
> Ouch. What was the % utilisation of the 2V6000? The biggest I've done is
> 50-60% and map and par times and memory usage haven't been unreasonable.
>
> We've had some regular BITGEN crashes on NT which haven't happened on
> 2000. Occasionally a PAR crash too.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 48154
Blackie Beard wrote:
> I'm not convinced that Verilog will let you use 'x' as a don't care.
> I do know that 'x' from a simulation result found on a wire is not
> a don't care, but an error (no signal driven, or contention)
>
x does not mean 'dont care' in this context
any 'x' bit in numeric compares (like <= > etc) results in an 'x' result.
== and != are different - they return false (or true) if they are are
obviously true (false) and X otherwise. So for example:
4'bx011 == 4'b1011 returns x
4'bx001 == 4'b1001 returns 0
in fact a==b is exactly the same as &(a^b) in so far as 'x's are concerned
Paul
Article: 48155What is it that you are trying to accomplish by doing this? "C.W. THomas" <cwthomas@bittware.com> wrote in message news:<uqehv4ldnktrff@corp.supernews.com>... > HI; > > > What is the attribute to keep a component from being optimized away in ise > 4.2?? > > thanks;Article: 48156
Ya, in an FPGA, use async reset. Besides, using sync resets sucks up one of your 4 inputs for your LUTs feeding resetable flops. > Any hints or suggestions? > > Cheers, > XanatosArticle: 48157
I found surprisingly little material about programming the FPGA myself. The (Altera-) tools pproduce *.pof & *.sof files and usually send them through the attached programmer. I wasn't able to find a reference about their format or how they are going to be sent to the FPGA or its config-chip. Only the JTAG interface was described. Any hints ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 48158
Ray Andraka wrote > The whole thing compiles in about 6 hours on an 800 MHz P3 with 1GB > memory with lots of paging under 4.2i with NT. Gets a memory conflict > under win2K while reading the .ncd, which is just over 100MB. How big was the EDIF? I hate the binary format. Searching through text is not for fun, but with a binary file you are up the river without a paddle if something goes wrong.Article: 48159
There are 4 edifs (components created separately and instantiated as black
boxes to speed up synthesis), 10.6 MB, 1.4MB, 128kB and 12.9MB
Tim wrote:
> Ray Andraka wrote
> > The whole thing compiles in about 6 hours on an 800 MHz P3 with 1GB
> > memory with lots of paging under 4.2i with NT. Gets a memory conflict
> > under win2K while reading the .ncd, which is just over 100MB.
>
> How big was the EDIF?
>
> I hate the binary format. Searching through text is not for fun, but
> with a binary file you are up the river without a paddle if something
> goes wrong.
--
--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: 48160
I heartily disagree. First, modern FPGAs have an option for synchronous
direct resets, so you don't lose a LUT pin. Even in the older families,
we used sync resets where possible, and when we couldn't we did the async
resets to small amounts at a time (eg one accumulator) and drove it with
a flip-flop floorplanned to be right where it is needed. The problem
with async resets is the critical timing is from driver of the reset pin
THROUGH the flip flop you are resetting and to the next flip-flop in the
chain. Not only that, but the timing tools did not consistently find
that timing path.
As to the original inquiry, you need to work up a circuit that holds the
reset in the first clock domain until the reset in the second domain also
happens, something like this:
process(clk1)
begin
if rising_edge(clk1) then
if reset_input='1' then
reset1<='1';
elsif resync_reset2='1' then
reset1<='0';
end if;
resync_reset2<= reset2;
end if;
end process;
process(clk2)
begin
if rising_edge(clk2) then
reset2<=reset1; --resync reset to this clock domain
end if;
end process;
Jay wrote:
> Ya, in an FPGA, use async reset. Besides, using sync resets sucks up
> one of your 4 inputs for your LUTs feeding resetable flops.
>
> > Any hints or suggestions?
> >
> > Cheers,
> > Xanatos
--
--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: 48161ldoolitt@recycle.lbl.gov (Larry Doolittle) writes: > On 11 Oct 2002 00:10:33 +0200, Neil Franklin <neil@franklin.ch.remove> wrote: > >Xilinx has already [made a publicly available API for their devices]. > >It is called JBits. Mail to jbits@xilinx.com to get an FTP URL and > >password to download it (its free as in free beer). > > Free beer doesn't normally come with an NDA. Neither does JBits. At least I was never presented with, nor have signed an NDA. And I of principle do not sign anythign that forces me to withhold information from anyone, and consider NDAs an total KO criterium for using anything. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48162
This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C27248.52566280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am making some simple FPGAs on a breadboard. What is the procedure to store the programming bits in my smartmedia card? Is it possible to put a SmartMedia Reader on a normal CPLD which will load the FPGA bits on startup? Thanks.Article: 48163
rickman <spamgoeshere4@yahoo.com> writes: > Neil Franklin wrote: > > > > Given that they can not[1] stop open source tools, they are going to have > > to learn to live with them when they arrive (which is just a question > > of time, nothing else). They can only delay them by not helping (which > > they will not help, also for liability and support cost reasons, which > > I fully agree with them). > > They can not in the sense of copyright infringement or patent issues > perhaps. That is the only "stop dead" type of stopping. And so the only deadly one to open source developers. And so the only one that I mind. Technical problems we can handle. An buch of armed law enforcers saying "stop or we arrest you (or kill if you resist) for daring our rulers" we can not. > But if they don't have the inside scoop on the chips, they > will have a long row to hoe. That is not "stop dead", just delay. Better late than never. A lot better. > That brings us back to one of my points. > The open source tools will *never* be up to date. The chip cycle is > just too short for a bunch of freeware guys to keep up with. Xilinx still sells XC4000/Spartan. After that came XC4000XL/Spartan-XL, then Virtex/Spartan-II, then Virtex-E/Spartan-IIE, then Virtex-II, now Virtex-IIpro. That makes 6 families being sold in parallel. Actually 3 large families, with each 2 subfamilies. Looks like an active sales life of about 10 years for one particular family. So any tool supporting Virtex/Spartan-II in say 1-2 years, and extendable to Virtex-E/Spartan-IIE, has at least an 5 year market life in it. Reverse-engineering Virtex-II should not take 5 years, so we can keep up... > who say it is inevitable. But we never see the tools... You can now see an actual project, started, that has an planned out path leading to tools. > > When my tools arrive, it is going to be Xilinx that profits (because I > > started from JBits out). And any extra chip they sell because of them > > will be the best "thanks" (dollars, not words) I can give them for > > enabling my stuff. > > And when can we expect this tool? First minimal stuff in estimated 1 years time, decently usable in 2 years, is my current estimate. > What devices will it support? Initially Virtex/Spartan-II (what JBits does), later Virtex-E/Spartan-IIE. > What > will be *better* about it than the tools already in use? All that in open source is better: - simple download/compile/install/use, any computer/OS native - no licensing, can give copy to anyone. allows "config&compile at customers site" designs, and yes, that includes "customer selects modules and generates bitstream that runs them" style adaption to modular interface hardware (see recompiling Linux kernel as an example) - bugs can be fixed by anyone, or more likey have already got fixed before you ever hit them, even OpenBSD style code audits go - guaranteed to remain available (because user-adaptable to new systems ad infinitum), no forced upgrade cycle - anyone can add their brains to development, wherever they have the expertise (compare the open process of science vs pronouncements from high from any closed governing body) For such features many (including myself) are willing to sacrifice using the latest chip family for the time needed to reverse-engineer, dito also not wringing the last drop of power out of an chip. > > And in the embedded market (more similar to FPGAs than desktop PCs > > are) we see 8051s from various cloners (with different feature sets) > > and official Intel tools vs open source ones. > > This has also been discussed before. Compilers have become commodity > items where one is about as good as another for 99% of the work done > with them. FPGA software is still in the stage of being very highly > tuned to the chip else it is of little value. FPGAs are newer than CPUs, they are bound to be at an earlier stage in the normal industrial process from novelty to mature technology. Screws from one manufacturer once did not fit nuts from an other, about 120 years ago, due to everyone using their own threads. Once the basic issues and design space in thread design were explored, standards came. > If you are doing simple > designs in uncrowded chips then you don't care what tools you use, but > most FPGA users push their designs if not initially, they do when being > upgraded in the field. They need tools that work very well with their > chip. How many today forgo the ultimate performance of FPGA Editor in favor of the simpler life with VHDL or Verilog? How many forgo the power increases of floorplanning for less work? How many are going to soon start using things like Handel-C because programmer time costs more than chip space (in small series work)? There exist "ultimate power" users, and they will demand "ultimate power" tools (and pay for them). There also exist less demanding users who will put up with an less powerfull tools if they offer them an better deal for their particular circumstances. It is horses for courses. > > I expect an similar open/wide/basic vs vendor/power/complex split in > > FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$), > > and the cost structure of their paying customers, they should be able > > to do this. > > You can expect what you want, but that won't make it happen. There are > very few engineers that are going to start a significant project with > open source FPGA tools when their company will pay for the commercial > tools. Some companies can expect an >5-digit profit increase from 5-digit tools. They will stay with them (stupid if they did not). Others can not expect such added profits, they already today do not afford them (they are those that today demand free Webpack&so on). > You make a lot of predictions that won't be tested for 10 years > or more. Anyone planning on shaping the future has to make predictions. The best we can do is look for similar cases. CPUs, in particular embedded/DSP are the nearest case. It happened there. > Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit > tools (unless you are counting the pennies). The expensive tools are > the synthesis and simulation tools. I was talking of those. > These are third party and they > charge so much because they are so good. And all the better for their makers, an for those users (their customers), that can convert such tools into the profit that can pay for them. They prove my point: vendor tools will not die (that was your claim) just because open source tools appear and reduce user count of vendor tools. Vendor tools can survive in that market. > But this is the first place > that open-source tools should show up. Why? Those that can pay have no needs. They are satified (nice for them). Those that can not pay have needs. Those that want open stuff have needs. And those that are unsatisfied are those that will experiment with new stuff, and accept the costs of working with untried stuff. > All the interfaces are defined > in public standards, the functionality is known, all that is needed is > the open source code. So where is it??? Where are the open source > synthesizers and simulators? You are forgetting the most important part of open source: motivation. It takes a lot of it. To accept sacrifice of the time to make software without pay. That motivation must come from somewhere. Look for the "somewheres" if you want to know where to look for the first appearances. > they are much more like the gcc target. But the back end tools are very > different. *That* is why there are no third party back end tool > vendors. They are software, like all other. I.e. designs to be specced, lines of implementing program code to be written, work time to be spent. That process is well understood. > > > FPGA tools > > > are a moving target and very different from software development tools. > > > Every new generation of FPGAs require very different software. > > > > So did every generation of CPUs in the days when every generation had > > an new instruction set. Today it is less work, because we have binary > > compatibility and improvement goes into making the existing "bitfiles" > > (read: binary applications) move faster. > > As soon as the x86 came out (~1981, IIRC) the basic instruction set was > cast in concrete. About 5 years later compilers matured and by 1991 > they had become commodities. 8086 was 1977 or 78, 8088 one year later. 386 was an massive update, nearly a new architecture, around 1984. Neither were particularly compiler friendly. But I expect 5 years "catch up" to be realistic for FPGA tools. > > I expect FPGAs will have to go the same route: mass market with binary > > compatibility, cloners[2], etc and an more diversifed "specialist" market > > where everything goes, for max performance, at high price. > > Patents will stop cloners. There is no market force driving FPGAs in > this direction, just as there is no market force driving all CPU makers > to adopt a common instruction set. Huh? I never said "all" CPUs, nor did I say all FPGAs. I clearly stated 2 markets, "mass" and "specialist". > > The Virtex vs Spartan split already points in that direction. Think of > > an non-compatible max-power series of Virtex-II, -III, -IV, -V and an > > Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, > > -IIX, -II? as an possible future. > > I'm not sure what you mean by this. Are you talking about a competitor > chip? Xilinx won't let that happen... No I was pointing out an possible development path for Xilinx. If binary compatible becomes important, they can play with it. You claimed that binary incompatible is neccessary, and as such will break tools, I pointed out that binary compatibility is possible in this market, just as it turned out to be in CPUs, and sketched what its result could look like. > > [2] Think of the next Clearpath with the same size relationship to Altera > > or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible > > SRAM based chips (not mask based specials). Drop in replacement, like an > > AMD K6 (what I am typing this on) fitting an Pentium I socket. And an > > power/price race ensuing, fought on process technology and feature. > > I think you mean Clearlogic... and they have gone the way of the dodo > bird because of infringement issues. And those were infringment on the software licenses on the Altera devel tools used to make the bitstreams that 100% of all their customers would be sending them. It is interesting that Altera did not chose the direct course of attacking them with their patents on the actual chip technology. That they needed to use such an indirect method of helping users breach the the devel tools software license, which is less likely to succeed in court, is telling us a lot. > AMD could make parts that fit the Pentium socket because they had a > license for that. After Socket 7 (IIRC) they no longer had that license > and they now have to make their own interfaces. Socket 7 did not require any license. It is only with Slot 1 and later Socket 370 that Intel introduced an patented signalling protocol (not pinout) which required an license that they then refused to AMD. The pinout is copyable, but useless it one can implement the signalling. > No FPGA company is > going to let a startup copy their technology. No copying the technology is needed. Just making something compatible with the bitstreams. May not happen, may well happen. But it sould be kept in mind as something that could happen in an future bit-compatible market. > > The "magnet" is a running bitstream, and the shortest path to that is > > interesting. So the action starts at the back end. > > So you want to do the hardest part first, show the least result and have > your work obsoleted most rapidly? Also known as: do the most/first needed part first, show an actually usable result, and accept that obsolence will happen and require an "chase the moving target" attitude. gcc did/does this (different CPUs), Linux did/does this (different computer architectures). Sure. > > I started coding 2.5 months ago. I expect to arrive at 2nd milestone > > > > [3] http://neil.franklin.ch/Projects/VirtexTools/ > > I looked at your page and I do not see where you are headed. See the "2.5 months" (should have been 3.5, oops) remark? > Once you > have built all the parts of the intended toolchain, what will the flow > be? Tentatively (subject to changes while implementing): Users chosen language -> compiler (3rd party, multiple) -> design reduced to LUT-sized elements, relative placed, their connections reduced design -> vas (from my toolset) -> design fitted to LUTs/F5s/etc, absolute placed, connections to PIP lists placed/routed design -> vm and libvirtex it calls (from my toolset) -> .bit file to be used or displayed/debugged (using existing vd and vv) -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48164
One thing lost in this conversation is the following observation: Why is gcc/egcs generally such a respectibly good compiler? It's largely because many chip vendors paid cygnus to port GCC to their target, and to improve performance. Without this significant, eternal economic driving force, GCC wouldn't be the impressive compiler it is today. Nevertheless, compilers matter somewhat less (because processors are so fast) and the vendor compilers still produce significantly better results. Another important observation: Why would I want good openly available tools? Not for use: "free beer" tools are almost invariably better because they are usually restricted versions of the full suites. Any personal project is NOT going to be using some Virtex-E 2000, but a Spartan II or similar low cost, low size part. If I'm designing for a V2pro somethingorother or similar part not covered by the free-beer tools, I'm going to want the Xilinx support which comes with paying for the tools when dealing with large and complicated fabrics. Face it, you aren't paying the $1000s for the TOOLS, your paying $1000s for the ability to call Xilinx and get a clued answer. Xilinx doesn't make money on the tools, they just charge enough to select only serious customers. And if you are an academic, ask nicely and they will give you the full tools. I'd want "open source" or freely modifiable tools for academic experimenting, to make my life easier when trying out new optimizations or techniques. Yet the freely available stuff (pathfinger, VPR, etc) are targeted towards academic models of FPGAs, while I want to target commercial arrays as it is much easier to make compelling performance claims and comparisons when targeting the winners in the marketplace. Fortunatly, Xilinx (and I'm not sure about Altera) at least make it OK to tie in a research bit into their toolflow: Jbits allows direct editing and constructing of bitfiles, albeit at a very low level. XDL is a complete representation between placement and routing, routing and bifile generation, and a partial representation between mapping and placement. Before that, you can feed in EDIF. Having an open source Xilinx toolflow would have saved me probably 1 month of hacking, but wasn't necessary for me to do the research I wanted. >> The Virtex vs Spartan split already points in that direction. Think of >> an non-compatible max-power series of Virtex-II, -III, -IV, -V and an >> Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, >> -IIX, -II? as an possible future. > >I'm not sure what you mean by this. Are you talking about a competitor >chip? Xilinx won't let that happen... This doesn't make sense. Spartan is the "This is an old enough/cheap enough piece of silicon that we can sell it cheap". So it really is about 1.5 generations behind (since S2 is at the Virtex-E stage now), but only on the small scale. I imagine that in 3 years, we will have Spartan III-pro parts. >AMD could make parts that fit the Pentium socket because they had a >license for that. After Socket 7 (IIRC) they no longer had that license >and they now have to make their own interfaces. No FPGA company is >going to let a startup copy their technology. That was the whole "slocket" crap intel used with the P2, it was so they could patent the interface outside the ISA, so the cross-agreements wouldn't apply. So AMD instead acquired a liscence to the Alpha bus. This may end up blowing up in Intel's face in the long run, the Hammer has a really nice interface. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48165
Actually, a synchronous reset in the Xilinx architecture can (though doesn't have to) be implemented through the S/R line. No LUT input is used up. In the original post, a mention of @nedgedge resetn suggests the actual implementation would be an asynchronous control to each flop, BUT... When a reset is applied without any coherence to the local clocks, some elements in the design will release the reset in one clock period, the other elements will release on the next. By registering the reset signals in the local clock domains, the reset will be applied to all elements within that clock domain in one clock cycle and be subject to the timing constraints for the clock period constraint. The timing analysis is clean in the Xilinx design flow for synchronous resets without doubt. There *may* be a timing analysis switch for the async reset but I think I'm confusing this with propagating timing *through* an async reset rather than meeting the reset inactive setup time. Thankfully, many designs are tolerant of a reset inactive taking two (or more?) clock cycles for an async reset that is truly asynchronous to the clock domain. For those who are concerned about dependencies - getting a state machine out of alignment without a "safe" return-to-idle condition for instance - proper attention paid to the reset timing is a very good thing. Jay wrote: > Ya, in an FPGA, use async reset. Besides, using sync resets sucks up > one of your 4 inputs for your LUTs feeding resetable flops. > > >>Any hints or suggestions? >> >>Cheers, >>Xanatos >>Article: 48166
http://www.altera.com/literature/an/an116.pdf The key word is "Configuration" or "Configuring." I found this within four mouse clicks and I've only been hanging out at brand X's site lately. Rene Tschaggelar wrote: > I found surprisingly little material about programming the FPGA > myself. The (Altera-) tools pproduce *.pof & *.sof files and > usually send them through the attached programmer. > I wasn't able to find a reference about their format or how they > are going to be sent to the FPGA or its config-chip. > Only the JTAG interface was described. > > Any hints ? > > ReneArticle: 48167
CPLDs are typically not SRAM based and maintain their programming on startup. Take a look at the "System ACE" configuration solution from Xilinx, for instance. This method can use Compact Flash cards which is close to what you're looking for. Compact Flash is easier to use than SmartMedia cards because both systems need some intelligence in the interface; in SmartMedia, the intelligence is in the host or the reader while Compact Flash has the smarts on the card. This solution is great for the large FPGA designs but not so good for the little ones (cost and space). A JTAG programming cable is apparently pretty easy to put together so that you can program an on-board serial PROM for the SRAM based devices or a CPLD directly. It might be that you don't need to go to the "great length" of a card interface to achieve your objectives. Good luck. - a different John_H John Hsiu wrote: > I am making some simple FPGAs on a breadboard. What is the > > procedure to store the programming bits in my smartmedia card? > > Is it possible to put a SmartMedia Reader on a normal CPLD which will > > load the FPGA bits on startup? > > > > Thanks.Article: 48168
In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> wrote: >CPLDs are typically not SRAM based and maintain their programming on >startup. > >Take a look at the "System ACE" configuration solution from Xilinx, for >instance. This method can use Compact Flash cards which is close to >what you're looking for. Compact Flash is easier to use than SmartMedia >cards because both systems need some intelligence in the interface; in >SmartMedia, the intelligence is in the host or the reader while Compact >Flash has the smarts on the card. This solution is great for the large >FPGA designs but not so good for the little ones (cost and space). Unless, of course, your app would benefit from having some other storage beyond just teh configuration, in which case Compact Flash is nice. Compact Flash is nice and cheap for 32, 64, and 128 MB cards, with microdrives if you need 1 GB of storage. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48169
The hooks for third party development of open source are already available for
xilinx via jbits and XDL for those that are inclined to write their own mapping,
place and route tools. I don't think you really need source that is any more open
than that to make it possible for people to develop their own tool set. Still,
there is precious little visible as 3rd party stuff goes here. Probably has a lot
to do with the much smaller user base FPGAs have vs CPUs and the much harder task
that map, place and route is compared with compiling code to a CPU. The point is
the FPGA software is open enough for you to insert your tools at any point in the
chain except the final bitstream generation. That is plenty of lattitude to spin
your own tools for any of the hard parts, should you be up to the challenge and
have nothing better to do with your time.
Settling on a standard bitstream is also not likely to happen, as the bitstream is
much more dependent on the hardware than is an instruction set for a CPU. The
bitstream generally controls some pretty low level switches in the cells, so cell
architecture is going to directly influence the bitstream. It has to be this way
in order to keep the bitstream length manageable...every extra bit of encoding or
recoding is duplicated thousands of times on the chip. As hardware features come
in and out of fashion, the bitstreams have to change to accommodate the evolution
of the hardware. That evolution is going to be driven by individual innovations by
different companies, and since this is not a government effort, the companies will
want to keep the rights to their innovations. With a CPU, the cost of recoding an
instruction for compatibility is not huge since the instruction unit is not
duplicated all over the place, plus the instruction set is very limited. With an
FPGA, the 'instruction set' is essentially the bit stream, which I suppose could be
broken into smaller kernels but still it is orders of magnitude larger than a CPU
instruction set.
Neil Franklin wrote:
> rickman <spamgoeshere4@yahoo.com> writes:
>
> > Neil Franklin wrote:
> > >
> > > Given that they can not[1] stop open source tools, they are going to have
> > > to learn to live with them when they arrive (which is just a question
> > > of time, nothing else). They can only delay them by not helping (which
> > > they will not help, also for liability and support cost reasons, which
> > > I fully agree with them).
> >
> > They can not in the sense of copyright infringement or patent issues
> > perhaps.
>
> That is the only "stop dead" type of stopping. And so the only deadly
> one to open source developers. And so the only one that I mind.
>
> Technical problems we can handle. An buch of armed law enforcers
> saying "stop or we arrest you (or kill if you resist) for daring
> our rulers" we can not.
>
> > But if they don't have the inside scoop on the chips, they
> > will have a long row to hoe.
>
> That is not "stop dead", just delay. Better late than never. A lot better.
>
> > That brings us back to one of my points.
> > The open source tools will *never* be up to date. The chip cycle is
> > just too short for a bunch of freeware guys to keep up with.
>
> Xilinx still sells XC4000/Spartan. After that came XC4000XL/Spartan-XL,
> then Virtex/Spartan-II, then Virtex-E/Spartan-IIE, then Virtex-II, now
> Virtex-IIpro.
>
> That makes 6 families being sold in parallel. Actually 3 large families,
> with each 2 subfamilies. Looks like an active sales life of about 10
> years for one particular family.
>
> So any tool supporting Virtex/Spartan-II in say 1-2 years, and extendable
> to Virtex-E/Spartan-IIE, has at least an 5 year market life in it.
> Reverse-engineering Virtex-II should not take 5 years, so we can keep up...
>
> > who say it is inevitable. But we never see the tools...
>
> You can now see an actual project, started, that has an planned out
> path leading to tools.
>
> > > When my tools arrive, it is going to be Xilinx that profits (because I
> > > started from JBits out). And any extra chip they sell because of them
> > > will be the best "thanks" (dollars, not words) I can give them for
> > > enabling my stuff.
> >
> > And when can we expect this tool?
>
> First minimal stuff in estimated 1 years time, decently usable in 2
> years, is my current estimate.
>
> > What devices will it support?
>
> Initially Virtex/Spartan-II (what JBits does), later Virtex-E/Spartan-IIE.
>
> > What
> > will be *better* about it than the tools already in use?
>
> All that in open source is better:
>
> - simple download/compile/install/use, any computer/OS native
> - no licensing, can give copy to anyone. allows "config&compile at
> customers site" designs, and yes, that includes "customer selects
> modules and generates bitstream that runs them" style adaption to
> modular interface hardware (see recompiling Linux kernel as an example)
> - bugs can be fixed by anyone, or more likey have already got fixed
> before you ever hit them, even OpenBSD style code audits go
> - guaranteed to remain available (because user-adaptable to new
> systems ad infinitum), no forced upgrade cycle
> - anyone can add their brains to development, wherever they have the
> expertise (compare the open process of science vs pronouncements
> from high from any closed governing body)
>
> For such features many (including myself) are willing to sacrifice
> using the latest chip family for the time needed to reverse-engineer,
> dito also not wringing the last drop of power out of an chip.
>
> > > And in the embedded market (more similar to FPGAs than desktop PCs
> > > are) we see 8051s from various cloners (with different feature sets)
> > > and official Intel tools vs open source ones.
> >
> > This has also been discussed before. Compilers have become commodity
> > items where one is about as good as another for 99% of the work done
> > with them. FPGA software is still in the stage of being very highly
> > tuned to the chip else it is of little value.
>
> FPGAs are newer than CPUs, they are bound to be at an earlier stage in
> the normal industrial process from novelty to mature technology.
>
> Screws from one manufacturer once did not fit nuts from an other,
> about 120 years ago, due to everyone using their own threads. Once the
> basic issues and design space in thread design were explored, standards
> came.
>
> > If you are doing simple
> > designs in uncrowded chips then you don't care what tools you use, but
> > most FPGA users push their designs if not initially, they do when being
> > upgraded in the field. They need tools that work very well with their
> > chip.
>
> How many today forgo the ultimate performance of FPGA Editor in favor
> of the simpler life with VHDL or Verilog?
>
> How many forgo the power increases of floorplanning for less work?
>
> How many are going to soon start using things like Handel-C because
> programmer time costs more than chip space (in small series work)?
>
> There exist "ultimate power" users, and they will demand "ultimate
> power" tools (and pay for them). There also exist less demanding users
> who will put up with an less powerfull tools if they offer them an
> better deal for their particular circumstances.
>
> It is horses for courses.
>
> > > I expect an similar open/wide/basic vs vendor/power/complex split in
> > > FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$),
> > > and the cost structure of their paying customers, they should be able
> > > to do this.
> >
> > You can expect what you want, but that won't make it happen. There are
> > very few engineers that are going to start a significant project with
> > open source FPGA tools when their company will pay for the commercial
> > tools.
>
> Some companies can expect an >5-digit profit increase from 5-digit
> tools. They will stay with them (stupid if they did not). Others can
> not expect such added profits, they already today do not afford them
> (they are those that today demand free Webpack&so on).
>
> > You make a lot of predictions that won't be tested for 10 years
> > or more.
>
> Anyone planning on shaping the future has to make predictions. The
> best we can do is look for similar cases. CPUs, in particular
> embedded/DSP are the nearest case. It happened there.
>
> > Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit
> > tools (unless you are counting the pennies). The expensive tools are
> > the synthesis and simulation tools.
>
> I was talking of those.
>
> > These are third party and they
> > charge so much because they are so good.
>
> And all the better for their makers, an for those users (their
> customers), that can convert such tools into the profit that can pay
> for them.
>
> They prove my point: vendor tools will not die (that was your claim)
> just because open source tools appear and reduce user count of vendor
> tools. Vendor tools can survive in that market.
>
> > But this is the first place
> > that open-source tools should show up.
>
> Why? Those that can pay have no needs. They are satified (nice for them).
>
> Those that can not pay have needs. Those that want open stuff have
> needs. And those that are unsatisfied are those that will experiment
> with new stuff, and accept the costs of working with untried stuff.
>
> > All the interfaces are defined
> > in public standards, the functionality is known, all that is needed is
> > the open source code. So where is it??? Where are the open source
> > synthesizers and simulators?
>
> You are forgetting the most important part of open source: motivation.
> It takes a lot of it. To accept sacrifice of the time to make software
> without pay. That motivation must come from somewhere. Look for the
> "somewheres" if you want to know where to look for the first appearances.
>
> > they are much more like the gcc target. But the back end tools are very
> > different. *That* is why there are no third party back end tool
> > vendors.
>
> They are software, like all other. I.e. designs to be specced, lines
> of implementing program code to be written, work time to be spent.
> That process is well understood.
>
> > > > FPGA tools
> > > > are a moving target and very different from software development tools.
> > > > Every new generation of FPGAs require very different software.
> > >
> > > So did every generation of CPUs in the days when every generation had
> > > an new instruction set. Today it is less work, because we have binary
> > > compatibility and improvement goes into making the existing "bitfiles"
> > > (read: binary applications) move faster.
> >
> > As soon as the x86 came out (~1981, IIRC) the basic instruction set was
> > cast in concrete. About 5 years later compilers matured and by 1991
> > they had become commodities.
>
> 8086 was 1977 or 78, 8088 one year later. 386 was an massive update,
> nearly a new architecture, around 1984. Neither were particularly
> compiler friendly.
>
> But I expect 5 years "catch up" to be realistic for FPGA tools.
>
> > > I expect FPGAs will have to go the same route: mass market with binary
> > > compatibility, cloners[2], etc and an more diversifed "specialist" market
> > > where everything goes, for max performance, at high price.
> >
> > Patents will stop cloners. There is no market force driving FPGAs in
> > this direction, just as there is no market force driving all CPU makers
> > to adopt a common instruction set.
>
> Huh? I never said "all" CPUs, nor did I say all FPGAs. I clearly
> stated 2 markets, "mass" and "specialist".
>
> > > The Virtex vs Spartan split already points in that direction. Think of
> > > an non-compatible max-power series of Virtex-II, -III, -IV, -V and an
> > > Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM,
> > > -IIX, -II? as an possible future.
> >
> > I'm not sure what you mean by this. Are you talking about a competitor
> > chip? Xilinx won't let that happen...
>
> No I was pointing out an possible development path for Xilinx. If
> binary compatible becomes important, they can play with it.
>
> You claimed that binary incompatible is neccessary, and as such will
> break tools, I pointed out that binary compatibility is possible in this
> market, just as it turned out to be in CPUs, and sketched what its
> result could look like.
>
> > > [2] Think of the next Clearpath with the same size relationship to Altera
> > > or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible
> > > SRAM based chips (not mask based specials). Drop in replacement, like an
> > > AMD K6 (what I am typing this on) fitting an Pentium I socket. And an
> > > power/price race ensuing, fought on process technology and feature.
> >
> > I think you mean Clearlogic... and they have gone the way of the dodo
> > bird because of infringement issues.
>
> And those were infringment on the software licenses on the Altera
> devel tools used to make the bitstreams that 100% of all their
> customers would be sending them.
>
> It is interesting that Altera did not chose the direct course of
> attacking them with their patents on the actual chip technology. That
> they needed to use such an indirect method of helping users breach the
> the devel tools software license, which is less likely to succeed in
> court, is telling us a lot.
>
> > AMD could make parts that fit the Pentium socket because they had a
> > license for that. After Socket 7 (IIRC) they no longer had that license
> > and they now have to make their own interfaces.
>
> Socket 7 did not require any license. It is only with Slot 1 and later
> Socket 370 that Intel introduced an patented signalling protocol (not
> pinout) which required an license that they then refused to AMD. The
> pinout is copyable, but useless it one can implement the signalling.
>
> > No FPGA company is
> > going to let a startup copy their technology.
>
> No copying the technology is needed. Just making something compatible
> with the bitstreams. May not happen, may well happen. But it sould be
> kept in mind as something that could happen in an future bit-compatible
> market.
>
> > > The "magnet" is a running bitstream, and the shortest path to that is
> > > interesting. So the action starts at the back end.
> >
> > So you want to do the hardest part first, show the least result and have
> > your work obsoleted most rapidly?
>
> Also known as: do the most/first needed part first, show an actually
> usable result, and accept that obsolence will happen and require an
> "chase the moving target" attitude. gcc did/does this (different CPUs),
> Linux did/does this (different computer architectures). Sure.
>
> > > I started coding 2.5 months ago. I expect to arrive at 2nd milestone
> > >
> > > [3] http://neil.franklin.ch/Projects/VirtexTools/
> >
> > I looked at your page and I do not see where you are headed.
>
> See the "2.5 months" (should have been 3.5, oops) remark?
>
> > Once you
> > have built all the parts of the intended toolchain, what will the flow
> > be?
>
> Tentatively (subject to changes while implementing):
>
> Users chosen language -> compiler (3rd party, multiple)
> -> design reduced to LUT-sized elements, relative placed, their connections
> reduced design -> vas (from my toolset)
> -> design fitted to LUTs/F5s/etc, absolute placed, connections to PIP lists
> placed/routed design -> vm and libvirtex it calls (from my toolset)
> -> .bit file to be used or displayed/debugged (using existing vd and vv)
>
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
> - hardware runs the world, software controls the hardware
> code generates the software, have you coded today?
--
--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: 48170The *.rbf files are raw binary files. Does anyone from Altera know of a documents that describes their programming format. Xilinx has a little bit about it in its all of its data sheets. They have a much more in depth app note about it. Is it possible to do partial configuration with Altera parts? Steve "John_H" <johnhandwork@mail.com> wrote in message news:3DA8657B.6070800@mail.com... > http://www.altera.com/literature/an/an116.pdf > > The key word is "Configuration" or "Configuring." I found this within > four mouse clicks and I've only been hanging out at brand X's site lately. > > Rene Tschaggelar wrote: > > > I found surprisingly little material about programming the FPGA > > myself. The (Altera-) tools pproduce *.pof & *.sof files and > > usually send them through the attached programmer. > > I wasn't able to find a reference about their format or how they > > are going to be sent to the FPGA or its config-chip. > > Only the JTAG interface was described. > > > > Any hints ? > > > > Rene >Article: 48171
On Fri, 11 Oct 2002 09:55:17 -0400, "C.W. THomas" <cwthomas@bittware.com> wrote: >Thanks! www.fpga-faq.comArticle: 48172
Ok there are 10 of us in the world who want to have Open source tools of some sort. My problem is I want to make a living off of the tools I write. How do I do this. When Red Hat was doing Linux some of the people working on their stuff got stock but most didn't. Is that viable here? Is there some model where we can all make money? I'm sure that 10 part time people could make place and route tool along with a very good gui. Will people pay for that kind of tool? I'm working on tools that Xilinx does not offer like being able to read, change and update a device while it is in operation. Being able to do this over a network between different operating systems. JBits only works for V1 flavors right now and they might pull the rug on it at any time so I don't think it is wise to depend on it. Steve > > I'd want "open source" or freely modifiable tools for academic > experimenting, to make my life easier when trying out new > optimizations or techniques. >Article: 48173
Even if they do pull the plug, it gives you a platform to develop and test your
tools with (and use them) before they do, then if they do the only piece you
need to add would be the equivalent of a jbits bit generator.
Steve Casselman wrote:
> Ok there are 10 of us in the world who want to have Open source tools of
> some sort. My problem is I want to make a living off of the tools I write.
> How do I do this. When Red Hat was doing Linux some of the people working on
> their stuff got stock but most didn't. Is that viable here? Is there some
> model where we can all make money? I'm sure that 10 part time people could
> make place and route tool along with a very good gui. Will people pay for
> that kind of tool? I'm working on tools that Xilinx does not offer like
> being able to read, change and update a device while it is in operation.
> Being able to do this over a network between different operating systems.
> JBits only works for V1 flavors right now and they might pull the rug on it
> at any time so I don't think it is wise to depend on it.
>
> Steve
>
> >
> > I'd want "open source" or freely modifiable tools for academic
> > experimenting, to make my life easier when trying out new
> > optimizations or techniques.
> >
--
--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: 48174
By the way, In this context, I think it does make sense at least as a starting
point, to use the hooks into the existing tool chain. Developing tools not
available in the current chain is certainly the most legitimate reasons for the
goals of the open source movement. I am aware of others developing tools that
fit in with the xilinx tools using xdl and/or jbits as well, all for adding
capabilities not in the current tools.
I think this thread started like many of the others along these lines where
someone wants to do their own PAR because the tools are too expensive. That
motivation, oversimplifies the monumental task of doing a good place and route.
If one was to do that, I would still encourage breaking it down to subtasks and
using the existing tools as a framework so that you don't need the whole ball of
wax working to prove out the part you are working on. With that in mind, I
think the most profitable use of time in these cases is to concentrate on adding
value rather than duplicating what is already there.
Steve Casselman wrote:
> Ok there are 10 of us in the world who want to have Open source tools of
> some sort. My problem is I want to make a living off of the tools I write.
> How do I do this. When Red Hat was doing Linux some of the people working on
> their stuff got stock but most didn't. Is that viable here? Is there some
> model where we can all make money? I'm sure that 10 part time people could
> make place and route tool along with a very good gui. Will people pay for
> that kind of tool? I'm working on tools that Xilinx does not offer like
> being able to read, change and update a device while it is in operation.
> Being able to do this over a network between different operating systems.
> JBits only works for V1 flavors right now and they might pull the rug on it
> at any time so I don't think it is wise to depend on it.
>
> Steve
>
> >
> > I'd want "open source" or freely modifiable tools for academic
> > experimenting, to make my life easier when trying out new
> > optimizations or techniques.
> >
--
--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
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