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
So if you send the internal signals that currently connect to the ICAP off-chip and back to the SelectMAP pins instead, you can get a speed boost? Pierre-Olivier -- to contact me directly, remove the obvious from my email address --Article: 62876
Hi Jim,
I see we have a difference of opinion. I'm not going to try to
change your mind, only answer the additional questions you posed:
> > For a general purpose FPGA, with general purpose programmable
> > I/O, you need this on every pin... While the end user makes
> > a selection via the bitstream, the actual hardware has to be
> > capable of handling all possible configurations.
>
> Not true. Some of the more esoteric IOs are already 'blocked'
> Users could live with not having 5V IO on every single IO,
> jus like they live with not having 840MHz SerDes on every IO.
There are no Xilinx devices like this. With the exception of
the gigabit serial I/O, all I/O pins are the same.
There are some vendors that have banking rules like you have
described, but even so, those banks don't support 5V I/O.
> Depends on where you look, and why.
> On embedded controllers, 5V is actually making a comeback.
> Lattices' very newest CPLDs, added 5V tolerant IOs.
I am looking specifically at the FPGA market.
> Give the customers some hard numbers, and let them decide for
> themselves :)
Most vendors have limited resources, and so make intelligent
guesses about price/feature tradeoffs. The market is wide open
for someone do exactly what you suggest.
> Some numbers ? XX cents per pin ?
I don't have this information. If I did, I'm sure my employer
would not be pleased if I were to share it. However, I do know
that the expense is considerable:
1. Additional mask sets.
2. Additional processing steps.
3. Cost of lost general purpose I/O.
4. Cost of a low volume, "novelty" product,
including software, support, and documentation.
It would be more expensive. I don't know how much. Time will
tell if FPGA vendors think this is a good return on investment.
Eric
Article: 62877news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>... > Or do a reimplementation of picoblaze or microblaze or xr16. I believe > that Xilinx won't mind another Microblaze implementation that helps > selling there Chips. (Göran, can you comment on that?) Once a version of microblaze becomes widely available on the Cyclone series (or other Altera chip) and starts selling Altera chips, I'm sure Xilinx would mind. :) JakeArticle: 62878
"Goran Bilski" <goran@xilinx.com> wrote in message news:booi3e$bg72@cliff.xsj.xilinx.com... > Hi Symon, > But someone started from scratch, the design would probably not be so > biased against Xilinx. > Perhaps you should do one that is biased *towards* Xilinx parts ;-) RalphArticle: 62879
Well, MicroBlaze is biased against Xilinx FPGA. The whole ISA is done towards our devices. That's why I mean it will probably not be efficient in other FPGA vendors architecture. But I think it would be very suited for an ASIC implementation. Göran Ralph Mason wrote: >"Goran Bilski" <goran@xilinx.com> wrote in message >news:booi3e$bg72@cliff.xsj.xilinx.com... > > >>Hi Symon, >> >> > > > >>But someone started from scratch, the design would probably not be so >>biased against Xilinx. >> >> >> > >Perhaps you should do one that is biased *towards* Xilinx parts ;-) > >Ralph > > > >Article: 62880
Eric Crabill wrote: > <snip > > Depends on where you look, and why. > > On embedded controllers, 5V is actually making a comeback. > > Lattices' very newest CPLDs, added 5V tolerant IOs. > > I am looking specifically at the FPGA market. Quite understood. I am looking from a designers viewpoint, across many markets, and asking 'why' wrt a specific feature. > > > Give the customers some hard numbers, and let them decide for > > themselves :) > > Most vendors have limited resources, and so make intelligent > guesses about price/feature tradeoffs. The market is wide open > for someone do exactly what you suggest. > > > Some numbers ? XX cents per pin ? > > I don't have this information. If I did, I'm sure my employer > would not be pleased if I were to share it. However, I do know > that the expense is considerable: > > 1. Additional mask sets. Accepted - perhaps one more, maybe none with the right cleverness. Note this mask would not be 0.13u, nor full die area. > 2. Additional processing steps. Yes, and it also requires that the foundry qualify the process, which requires their customers indicate they need it. This may come sooner than you think. I see foundries are now offering 110nm process as a 'back fill' between the 130nm and 90nm processes. Seems the customers are not rushing to 90nm quite as fast as they hoped - so a significant mindset change is occuring where smallest/fastest is no longer the sole target on the radar. > 3. Cost of lost general purpose I/O. Not sure they are mutually exclusive. An IC designer could exclude it on some specialist high speed IO. > 4. Cost of a low volume, "novelty" product, > including software, support, and documentation. The other markets releasing 'wide supply' ICs do not think they are "novelty" products - quite the reverse. Their intention is to have one die cover as many customers as practical, and reduce the part number proliferation, as well as extend the 'design life' of a given die. There are LOTS of benefits along the whole supply chain. LOGIC has now moved to 1.65-5.5V Vcc specs after some market failures with lower/narrower offerings. uC are following, with the better ones now doing 1.8-5.5V, or 2.0-5.5V - some uC and CPLD have on-die regulators. When you see the curves, you can appreciate the 1.8-5.5V was not easy, and not without effort or some silicon cost. Besides Wide Vcc, commercial temp spec releases are being dropped in favour of industrial (or wider) 'as standard'. > It would be more expensive. I don't know how much. Time will > tell if FPGA vendors think this is a good return on investment. See rickmans post, covers the trade-offs designers face and the reasons for device selection, nicely. -jgArticle: 62881
Symon wrote: > > Hi Goran, > So, playing devli's advocate, Xilinx wouldn't mind if the clean room > Microblaze was targeted at their competitors' devices? Or do you think that > no one would do this because Microblaze only efficiently fits the Xilinx > devices? Or the competitors have their own solutions for their parts? > I wonder.... Xilinx's protection does not come from attack on the clean room clone, but rather from the protection of the Microblaze name, and tool flows. So, anyone would be free to create an opcode compatible core, if they wished, but not to use the brand, nor the Xilinx tool flows. Older uC cores are easier to copy (any patents lapsed), and their tools are widely available. Things like 80C51, 6502, Z8, and even 8085.... ( someone must have done a 8048 core ? :) -jgArticle: 62882
Morten Leikvoll wrote: > I'm trying to get rid of all unconstrained nets and wonder how I can specify > max delay for nets that is (partly) used to reset DLL's. There are keywords > for FFS, LATCHES and RAMS, but none for DLLs? How about the MAXDELAY constraint?Article: 62883
Jake, Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other architectures. The specific features required are covered by patents. Austin Jake Janovetz wrote: > news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>... > > Or do a reimplementation of picoblaze or microblaze or xr16. I believe > > that Xilinx won't mind another Microblaze implementation that helps > > selling there Chips. (Göran, can you comment on that?) > > Once a version of microblaze becomes widely available on the Cyclone > series (or other Altera chip) and starts selling Altera chips, I'm > sure Xilinx would mind. :) > > JakeArticle: 62884
In article <3FAFFAE7.2939@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: > Xilinx's protection does not come from attack on the clean room clone, >but rather from the protection of the Microblaze name, and tool flows. > So, anyone would be free to create an opcode compatible core, >if they wished, but not to use the brand, nor the Xilinx tool flows. Isn't the compiler flow gcc? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 62885
The name MicroBlaze is a trademark of MicroBlaze. So a cleanroom can't be called MicroBlaze. For the tools part, yes, the EDK tools is our tools which we don't give away for free (they costs $495 and that's including all the IP) The actual compiler tools is GNU tools and they are open-sourced. Göran Jim Granville wrote: >Symon wrote: > > >>Hi Goran, >> So, playing devli's advocate, Xilinx wouldn't mind if the clean room >>Microblaze was targeted at their competitors' devices? Or do you think that >>no one would do this because Microblaze only efficiently fits the Xilinx >>devices? Or the competitors have their own solutions for their parts? >> I wonder.... >> >> > > Xilinx's protection does not come from attack on the clean room clone, >but rather from the protection of the Microblaze name, and tool flows. > So, anyone would be free to create an opcode compatible core, >if they wished, but not to use the brand, nor the Xilinx tool flows. > > Older uC cores are easier to copy (any patents lapsed), and their tools >are widely available. Things like 80C51, 6502, Z8, and even 8085.... > ( someone must have done a 8048 core ? :) > >-jg > >Article: 62886
In article <3FB0002A.909E765A@xilinx.com>,
Austin Lesea <Austin.Lesea@xilinx.com> writes:
|> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
|> architectures. The specific features required are covered by patents.
I like the perversion of the word "patent".
"patere", lat.: "standing open".
SCNR(tm)
--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 62887
In article <3FAFDFB9.63CF0853@xilinx.com>, Eric Crabill wrote:
(posting from a Xilinx e-mail address)
>
>> On embedded controllers, 5V is actually making a comeback.
>> Lattices' very newest CPLDs, added 5V tolerant IOs.
>
> I am looking specifically at the FPGA market.
>
>> Give the customers some hard numbers, and let them decide for
>> themselves :)
>
> Most vendors have limited resources, and so make intelligent
> guesses about price/feature tradeoffs. The market is wide open
> for someone do exactly what you suggest.
Ahem. I think your company's lawyers would have something
to say if anyone but you, and maybe Altera, tried anything
of the sort.
- Larry
Article: 62888Hi, I'm trying to write some code for a 64 bit counter for a VirtexII. The problem I'm facing is that it has to run at least at 200MHz, and therefore a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz). I've tried a split approach with four smaller counters and a selector depending on the carry out of the previous stages but it only got me to about 180MHz. Did anyone ever had a similar problem and solved it ? Unfortunately I'm not familiar with a pipelined implementation, I'll be happy to learn one. Many thanks, Erez.Article: 62889
Hello, I would like to know does anyone knows, is it possible to reverse engineer an edif netlist file? I am currently developing an FPGA core. I would like to supply an evaluation version of the core, that would have all the functionality of the final core, but would operate only for a limited period of time. My fear is that there is a way to modify the evaluation version edif netlist (find and remove modules that set a time limit to the operation of the evaluation version), and thus obtain completely functional core. Can something like this be done, or am I being paranoid? Every help and clarification on this subject is most welcome. Thanks in advance, Rastislav StruharikArticle: 62890
Georg Acher wrote: > In article <3FB0002A.909E765A@xilinx.com>, > Austin Lesea <Austin.Lesea@xilinx.com> writes: > > |> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other > |> architectures. The specific features required are covered by patents. > > I like the perversion of the word "patent". > > "patere", lat.: "standing open". Which is precisely what they do - the details are published (ie open), but there is protection for the inventor to profit exclusively from that invention for a limited period of time. A reasonable idea in principle - it's the rampant abuse that is the problem. Regards, JohnArticle: 62891
Nicholas C. Weaver wrote: > In article <3FAFFAE7.2939@designtools.co.nz>, > Jim Granville <jim.granville@designtools.co.nz> wrote: > > >>Xilinx's protection does not come from attack on the clean room clone, >>but rather from the protection of the Microblaze name, and tool flows. >>So, anyone would be free to create an opcode compatible core, >>if they wished, but not to use the brand, nor the Xilinx tool flows. > > > Isn't the compiler flow gcc? It is indeed. I host a copy of the tools on my website, and one may build entire microblaze linux kernels without paying a cent to Xilinx. Of course, you won't have a processor to run it on unless you do! Same as any gcc-targeted processor really. Regards, JohnArticle: 62892
> > Once a version of microblaze becomes widely available on the Cyclone > series (or other Altera chip) and starts selling Altera chips, I'm > sure Xilinx would mind. :) > Did I mention that my new board design has a Cyclone on it? Hmmm, "The Cyclo-Blaze"...has sort of a nice ring to it. ;>) I guess if it's smaller than the Altera Nios and a lot simpler, it could be of some use. Anyway, it should be a good learning experience. Thanks again. BPArticle: 62893
You can use a one way hash function to do the reduction. A CRC is a good example, one can think of others. It will probably not solve your space problem though. Erez. "Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0311100448.1577e5c2@posting.google.com... > Dear Sir or Madame, > > I have a data packet which has a 13 bit field for an USB > application(7bit + 4bit + 1bit + 1bit). > > > Because of lack of memory I do create a RAM which > has a data input width of only 10 bit. The write address of > the RAM is [4..0], i.e. 32 words á 10 bit. > The words which are written into the RAM > are searched for later (CAM-like function). > > The problem: I have to reduce 13 bit to 10 bit without losing the > significance of the 13 bit. But it is not possible to leave out for > example > two bits of the 7bit (usb address) because the enumeration by the host > is not > predictable. > > How could I solve this problem? > > Thank you very much. > > Best regards > > Andres Vazquez > G&D System DevelopmentArticle: 62894
Sorry. An EDIF file should be pretty straight forward to reverse engineer. I have had to edit one before. You could make it difficult by obfusciating it. One method changes all names to be sequences of letters O and l and numbers 0 and 1. This would not deter those that are determined though. If there is money involved, people are determined. You would be better off working with a good legal agreement and people who you can trust to abide by it. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rastislav Struharik wrote: > Hello, > > I would like to know does anyone knows, is it possible to reverse > engineer an edif netlist file? I am currently developing an FPGA core. > I would like to supply an evaluation version of the core, that would > have all the functionality of the final core, but would operate only > for a limited period of time. My fear is that there is a way to modify > the evaluation version edif netlist (find and remove modules that set > a time limit to the operation of the evaluation version), and thus > obtain completely functional core. Can something like this be done, or > am I being paranoid? > Every help and clarification on this subject is most welcome. > > Thanks in advance, > Rastislav StruharikArticle: 62895
"Counter" can mean many things. If you need a synchronous counter that gives you the updated value before the next count pulse comes in, that is a demanding design and may have timing problems at 200 MHz. If, at the other extreme, you just need a counter that can resolve 200 ( or 500+ ) MHz, and you can wait some nanoseconds before you read the final count value, that is trivial. In the extreme case you would just concatenate 2-bit Johnson counters (at least at the input end), one slice clocking the next. And there are many variations on this theme. I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing around, aiming at 1 GHz now. Peter Alfke, Xilinx Applications Erez Birenzwig wrote: > > Hi, > > I'm trying to write some code for a 64 bit counter for a VirtexII. > > The problem I'm facing is that it has to run at least at 200MHz, and > therefore > a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz). > > I've tried a split approach with four smaller counters and a selector > depending on the carry out of the previous stages but it only got me to > about > 180MHz. > > Did anyone ever had a similar problem and solved it ? > Unfortunately I'm not familiar with a pipelined implementation, I'll be > happy > to learn one. > > Many thanks, > Erez.Article: 62896
"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:boogcg$2ft9$1@agate.berkeley.edu... > In article <2658f0d3.0311100853.4468d276@posting.google.com>, > Fernando <fortiz80@tutopia.com> wrote: > >As mentioned, the simultaneous switching will definitely be an issue. > >I never heard about this technique of switching different DRAM chips > >on different phases of the clock. Is it commonly used? > > I don't see why not, its a simple and elegant solution. Don't forget you're dealing with DDR DRAM, it already uses all the phases of the clock. From my experience running ~160 pins at 200MHz causes the FPGA to be very hot (~85C without a heat sink). Erez.Article: 62897
In article <TPUrb.50$%o4.11977@news.xtra.co.nz>, Erez Birenzwig <erez_birenzwig@hotmail.com> wrote: >Don't forget you're dealing with DDR DRAM, it already uses all the phases of >the clock. It's using both phases of a single clock, but that clock can be out of phase with other DRAM clocks, which seems to be the idea. >From my experience running ~160 pins at 200MHz causes the FPGA to be >very hot (~85C without a heat sink). Not suprising. But slap an Itanic heatsink on it! (IA64 heatsink can cool 130W). -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 62898
To be more precise the implementation requires the calculation of: a = a + 1 When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6 FPGA. Erez. "Peter Alfke" <peter@xilinx.com> wrote in message news:3FB01875.A2C23F2F@xilinx.com... > "Counter" can mean many things. > If you need a synchronous counter that gives you the updated value > before the next count pulse comes in, that is a demanding design and may > have timing problems at 200 MHz. > > If, at the other extreme, you just need a counter that can resolve 200 ( > or 500+ ) MHz, and you can wait some nanoseconds before you read the > final count value, that is trivial. In the extreme case you would just > concatenate 2-bit Johnson counters (at least at the input end), one > slice clocking the next. And there are many variations on this theme. > I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing > around, aiming at 1 GHz now. > > Peter Alfke, Xilinx Applications > > > Erez Birenzwig wrote: > > > > Hi, > > > > I'm trying to write some code for a 64 bit counter for a VirtexII. > > > > The problem I'm facing is that it has to run at least at 200MHz, and > > therefore > > a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz). > > > > I've tried a split approach with four smaller counters and a selector > > depending on the carry out of the previous stages but it only got me to > > about > > 180MHz. > > > > Did anyone ever had a similar problem and solved it ? > > Unfortunately I'm not familiar with a pipelined implementation, I'll be > > happy > > to learn one. > > > > Many thanks, > > Erez.Article: 62899
i am attempting to migrate my design environment for a legacy design based on older xilinx parts from win98 to XP. it's a key problem that would be resolved by getting non-hardware locked versions of these programs. if you have these, please forward them to me with the above subject line. if someone at xilinx can make them for me, the details are below. the details: currently, the compiling is done using a DOS based design flow in XNF format. the AHDL sections of the design are performed by ABL2XNF (v5.2.1), but this tool does not work under XP. it simply exits. this may be unrelated to the key problem, but it appears to be an unnecessary design flow gizmo - i ran the sub-tools directly under win98 and the finished result is identical. the ABL2XNF "sub-tools" are: AHDL2X, BLIFOPTX, SYNTHX, and IMPROVEX. AHDL2X and SYNTHX both fail in XP because the hardware key can not be read (though it is present). the other two programs are not locked. xilinx doc# 902 indicates the key needs a "rainport" driver for NT. this driver does not appear to work, but configuration information is not available, rainbow refuses requests for support indicating that the programs need to be re-linked with their new libraries (which are free) and then i will need their current drivers. xilinx tech support says "xilinx does not have the resources..." to support me on this. the real deal is that they don't know who to ask in development. it's probably a 10 minute job if the make-files exist. any xilinx coders out there care to help? it seems odd that these are the only two programs remain hardware locked when all of the programs which had previously been locked have been unlocked in newer versions. has anyone previously faced this problem and found a functional work-around? many thanks, bill
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