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
What I've done is wire a PHY eval board to a digilent SParten IIE board, and use am ethernet-lite core from the edk WITHOUT a softcore processor - i.e. just put a wrapper around the ethernet soft-core and drive the bus signals directly from a processes intimately associated with the data I was trying to communicate. I my I was doing only UDP broadcast of data I acquired within the eval board for consumption by an off-board test computer. Alfredo wrote: > Has anyone used the Ethernet add-on module for the Digilent Spartan3 > board? > http://www.digilentinc.com/info/NET1.cfm > > I want to back into design, and instead of doing the same old > uart/SERDES design I did years ago, I wanted to do something more > challenging. > > Thanks, > > *** > Alfredo. >Article: 85926
In Xilinx CoolRunner CPLDs the current consumed by each unused macrocell is already a small fraction of a microamp. Not worth any extra hoopla. Peter AlfkeArticle: 85927
I have been using the Coolruner for some time now. I use tools which I have written so I needed the programming data; back then, Philips gave me some of it (and what they did not give me - the ZIA multiplexing truth tables - I reverse engineered myself). When Xilinx took over, I tried to get such data for their newer parts, only to be told that I have to buy a $9 million worth parts per 3 months to be entitled to ask about these data. I did not bother asking after exactly which 3 months (the first or perhaps the tenth) I would be allowed to ask for the data again. Here comes the question to the group: has anyone ever been successful getting fusemap data from Xilinx? (under NDA or whatever). Another (less vital, more out of curiousity) question: Why is the secrecy? Can anyone suggest some other plausible reason for it except the obvious (control of their customers)? Please save the "why do you need it" and "they offer free tools" kinds of answers, I am aware of all this. Regards, Dimiter ------------------------------------------------------- Dimiter Popoff Transgalactic Instruments http://www.tgisci.com -------------------------------------------------------Article: 85928
dp@tgi-sci.com wrote:
> Here comes the question to the group: has anyone ever been
> successful getting fusemap data from Xilinx? (under NDA
> or whatever).
I don't write synthesis tools so
I would have no use for such data.
> Another (less vital, more out of curiousity) question:
> Why is the secrecy? Can anyone suggest some other plausible
> reason for it except the obvious (control of their customers)?
Sure. Not having to publish, verify, update and explain
a formal external document for every rev of every part.
Customers have too many options to be controlled in any case.
-- Mike Treseler
Article: 85929On 18 Jun 2005 09:08:28 -0700, "dp@tgi-sci.com" <dp@tgi-sci.com> wrote: >I have been using the Coolruner for some time now. >I use tools which I have written so I needed the >programming data; back then, Philips gave me some of it >(and what they did not give me - the ZIA multiplexing >truth tables - I reverse engineered myself). >When Xilinx took over, I tried to get such data for their >newer parts, only to be told that I have to buy >a $9 million worth parts per 3 months to be entitled >to ask about these data. I did not bother asking after exactly >which 3 months (the first or perhaps the tenth) I would be allowed >to ask for the data again. > > Here comes the question to the group: has anyone ever been >successful getting fusemap data from Xilinx? (under NDA >or whatever). > Another (less vital, more out of curiousity) question: >Why is the secrecy? Can anyone suggest some other plausible >reason for it except the obvious (control of their customers)? It costs time and money to provide this documentation in an end-user consumable form, and there would be little if any commercial benefit to them in doing it. If they had a policy of publishing a spec then it would make it harder for them to make changes to the silicon as the changes would need to be documented as well. If they have a limited number of people who need to know the details, then it's much easier (i.e. cheaper) to make sure everyone is up to date. Documentation may reveal details of the architecture etc. that they regard as trade secrets. It may also reveal possible patent infringements. So the bottom line is that it's just easier and cheaper for them not to publically document the internal details that the vast majority of customers have no need to know about.Article: 85930
>It costs time and money to provide this documentation in an end-user >consumable form, and there >would be little if any commercial benefit to them in doing it. Actually they have to document it properly either way. Many people work on such projects, how can you write all the software it takes without documentation. The question is, why is it kept secret. I am not asking for any explanations/support, I can make my way through the data. >Documentation may reveal details of the architecture etc. that they regard as >trade secrets. It may >also reveal possible patent infringements That's their public version, I know. Have you ever seen such data which does reveal any "trade secrets"? Nothing of the kind in the data I have been using so far. Dimiter -------------------------------------------------------------------------------- Dimiter Popoff Transgalactic Instrumets http://www.tgi-sci.com --------------------------------------------------------------------------------Article: 85931
Mounard le Fougueux wrote:
> I find writting that writing clk'ed "PROCESS"s in vhdl to be both easy
> to do as well as very reliable - that is, vhdl processes JUST work as
> long as you know what your doing and set realistic timing constraints.
> Thats no problem for me.
I agree. The synchronous process (always block) is
where the hardware and software worlds can converge.
This code can be viewed as an interrupt routine for
the event of a rising clock edge: Hello. What
state am I in? 42? OK. What are the inputs doing? OK, let's
update the outputs like this. See you next time in state 43.
Whatever the description language, this is what has
to be covered.
The hardware guys may miss this by using TTL
netlists because they don't trust synthesis.
The software guys may miss this because
there is no standard input or program completion
and the syntax is a little different than C.
> Most of my problems, however, are more "transactional" in nature - i.e.
> they have to do with communications between entities/processes across
> clock boundaries and/or interactions between data/signal
> producers/consumers driven by different external events. Not the timing
> within a process itself.
But you can put a lot in a process.
These problems can be addressed with design rules.
Synchronize inputs. Register outputs.
Minimize number of entities and processes.
Communicate between procedures using
process variables (blocking assignments).
Process data and control together.
Handshake external transactions (non-blocking assignments).
> So, driven by the nature of most of the tricky problems I have to deal
> with, I am obviously open to some way of analyzing my system on a
> transactoinal level so as to gain insight to the various design
> architectural issues - i.e. analyzing the tradoffs of different possible
> solutions to the problem at hand.
I do this with many functional simulations
interspersed with a few trial synthesis/route/static timing.
> So if anyone has any introductory transactional analysis references,
> which aren;t SystemC vendor or approach specific, I'd appreciate it.
I don't doubt that SystemC covers some of the
same territory, but how can you beat cycle-accurate
simulations backed by static timing analysis?
Start by reading these:
http://www.designabstraction.co.uk/HTML/articles.htm
> Thanks for listening to my rant!
Good stuff. Thanks for the posting.
-- Mike Treseler
Article: 85932
dp@tgi-sci.com wrote:
> Actually they have to document it properly either way.
That's not always the case.
Internal specs can be much more informal than external ones.
I have done NDAs involving only sketchy
text documents and indirect email Q and A.
Technical guys actually doing the work are
spread pretty thin.
-- Mike Treseler
Article: 85933>That's not always the case. >Internal specs can be much more informal than external ones. Well I would be happy with these informal data as well - under NDA or whatever. I never asked for more. Notice that this still does not explain the secrecy. They wanted me to make a $9 million quarterly revenue so I would be eligible to sign an NDA for these data (and they never said they did not have them). Dimiter ------------------------------=AD------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------=AD------------------------------------------Article: 85934
> There are legal precedent cases where the fine print has been too fine,
> or too far removed, from the headlines, and also where the fineprint
> essentially contradicts the headlines.
"The large print giveth, the small print taketh away."
- Tom Waits
Article: 85935Why these endless arguments? Dimitr, just read the postings in this thread, slowly and carefully. Documenting and maintaining documentation in publicly usable form is expensive. And the avarage user has no need to know the things you ask for, and would not even know what to do with the information. Those are two overwhelming reasons not to make the data public. PLD companies try to make money, and avoid waste. Now, if you are such a good customer that you sepnd $ 9M in a quesrter, we will be extra nice to you... Why is this difficult to understand? Peter AlfkeArticle: 85936
Peter Alfke, are you sure you read my postings? >Documenting and maintaining documentation in publicly usable form is >expensive Like I explained, I would be happy with the data as they are - under NDA or whatever. I made this clear from the very start and I did get the data from Philips, only Xilinx are secretive. > And the avarage user has no need to know the things you ask >for, and would not even know what to do with the information How often do average users ask for fusemap data under NDA and are denied it? How many of your average users do successfully use their internally written software to program Coolrunners based on what they could achieve before Xilinx took over and blocked it all? >Those are two overwhelming reasons not to make the data public Which of them do you think applies to my postings so far? >>Why is this difficult to understand? Dimiter ------------------------------=AD=AD-----------------------------=AD-------= ------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------=AD=AD-----------------------------=AD-------= ------Article: 85937
"Mounard le Fougueux" <Fougueux@daeventhorizon.com> wrote in message news:EradnRF6H9rNoSnfRVn-jg@adelphia.com... > I recently attended an FPGA vendor seminar that included some discussion > of SystemC, HandelC and MentorGraphicsC. [snip] Interesting. I was just wondering if SystemC et al are things that I should look into. Let me explain: Coming from the world of software (from embedded C/asm to databases/PL/SQL + some old shool hardware experience) to the world of HDL I found it very refreshing and very appropriate the way the tools in this area have developed. In my case I seem set to become a happy verilog and ISE user. I certainly don't want contrieved adaptions of non-HDLs and software development processes for my hardware design. In fact I'm so glad to find that verilog and the tools are just what they are. My first non-trivial HDL design is transactional in nature (packet switching) and the HDL is no hindrance. Quite the opposite - it makes things very clear. As has been said, hardware IS NOT software, and if your daily diet is realtime/low-level programming the distinction should be easy to appreciate. If one is a software guy getting into hardware and wanting to think in huge abstractions, non-timed environment etc., one might need to play some with soldering irons and oscilloscopes first ;-) Perhaps at some level of (co?) design complexity, these things (SystemC etc.) are really a necessity? On the other hand I've seen software be ruined by too much complexity and/or overhead in the languages, design and development processes, tools etc.. DJ --Article: 85938
dp@tgi-sci.com wrote: > Peter Alfke, > > are you sure you read my postings? > > >>Documenting and maintaining documentation in publicly usable form is >>expensive > > > Like I explained, I would be happy with the data as they are - under > NDA or whatever. I made this clear from the very start and I did get the > data from Philips, only Xilinx are secretive. So we know Philips <> Xilinx. >>And the avarage user has no need to know the things you ask >>for, and would not even know what to do with the information > > > How often do average users ask for fusemap data under NDA > and are denied it? How many of your average users do successfully > use their internally written software to program Coolrunners based > on what they could achieve before Xilinx took over and blocked it all? > > >>Those are two overwhelming reasons not to make the data public > > > Which of them do you think applies to my postings so far? Probably both ? [ and more -> what happens, if you believe the Data <> fuse ? - support bandwidth is needed ] Perhaps you should explain WHY their present tool flow is not good enough for your task, and how your flow is much better ? This is a serious point - you may well have soemthing Xilinx have not thought of, that could benefit everyone. There ARE intermediate formats, that enable you to get very close to the iron, and you then work only with their fitter portion of the tools. Last time I checked, the coolrunner flows were happy with TT2 and BLIF files. Have you looked at that ? -jgArticle: 85939
>or whatever. I made this clear from the very start and I did get the >data >from Philips, only Xilinx are secretive. Xilinx is still in the (C)PLD business. Philips isn't. Maybe that's because Philips didn't make the right decisions on things like this. Even though you may not need any support, it's hard to determine that ahead of time. If they give you the info and you can't understand it or it's buggy or ..., then you will be even more pissed off at them than you are now. If they give you the info, then the next guy who isn't so smart will expect to get it too. Somebody at Xilinx thinks that support or whatever would be too expensive for the amount of money they will get in return. How many $ do you spend on their chips? Do you have any alternatives? How much more $ will they get from you if they give you the info you want? ... Is it even worth it for them to think about the problem? I'm not sure what you want to do. As Jim Granville suggested, my guess is your best approach is to make your tools feed the back end of Xilinx's tool set. -- 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: 85940
I asked in my first mesage to save the mainstream sort of answers like "why do you need this" , "they offer it for free" etc. I am doing it again now. >Perhaps you should explain WHY their present tool flow is not good >enough for your task, and how your flow is much better ? My question was not why I needed the data, it was why Xilinx did not provide them - while I have been declaring all the time that I needed no support, _nothing_ except the data they _already_have_. I use no mainstream PCs or software in my design process. There are no tools for my platforms other than those I have written. I am not planning to begin planting potatos rather than continue to support and develop my OS, my systems, and my tools in favour of someone elses - not as long as I can make a living as the small tech company I am now anyway. I am not planning to offer my internally developed tools on the market so I'll skip the explanations why I prefer them to other tools which I did not write. >There ARE intermediate formats, that enable you to get very close to >the iron, and you then work only with their fitter portion of the tools. They invest more into writing appnotes explaining through which hoops to jump in order your file to make it to the chip via JTAG if you want it done "in system" than it would cost them to have it all documented (which I am pretty sure they have anyway). And yes, I am quite sure I can reverse engineer all their stuff if I invest a month or so in programming various tools to do that. I had to do it partly for the Philips parts as well, like I explained in my first message - but it took less work, I did it in a week or so. I'll do it again if I have to, of course. It takes way more than a cpld manufacturer to switch me into potato planting mode... Finaly a reminder: my main question was whether anyone has ever been successful getting fusemap data from Xilinx? Dimiter ------------------------------=AD=AD=AD----------------------------=AD-=AD-= ------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------=AD=AD=AD----------------------------=AD-=AD-= ------------Article: 85941
Dr Justice wrote: > "Mounard le Fougueux" <Fougueux@daeventhorizon.com> wrote in message > news:EradnRF6H9rNoSnfRVn-jg@adelphia.com... > >>I recently attended an FPGA vendor seminar that included some discussion >>of SystemC, HandelC and MentorGraphicsC. > > [snip] > > Interesting. I was just wondering if SystemC et al are things > that I should look into. Let me explain: > > Coming from the world of software (from embedded C/asm to > databases/PL/SQL + some old shool hardware experience) > to the world of HDL I found it very refreshing and very appropriate > the way the tools in this area have developed. In my case I seem > set to become a happy verilog and ISE user. My obervation during further research, is that Verlilog has some limitations at the high end, where VHDL really shines, and conversely vhdl, unaided, has limitations at the low end (how to model a "jumper" in vhdl?). It appears that systemC is intended to address some of the shortcomings of Verilog for verification (test benches)and larger systems that vhdl is great at. So, it apppears that systemC is really geared for verilog users, who seem to think that the "C-Like" aspects of Verilog is a plus. I personnally think that VHDL has enough power to not need a lot of the systemC stuff, and its distinction between "variable" (space) and "signals" (time) is just, well, wonderfull. However It would be nice to have some tools to guage the transactional level stuff, other just just old fashioned MS Power point, or Visio. > > I certainly don't want contrieved adaptions of non-HDLs and software > development processes for my hardware design. In fact I'm so glad to > find that verilog and the tools are just what they are. My first non-trivial > HDL design is transactional in nature (packet switching) and the HDL > is no hindrance. Quite the opposite - it makes things very clear. > > As has been said, hardware IS NOT software, and if your daily diet > is realtime/low-level programming the distinction should be easy to > appreciate. If one is a software guy getting into hardware and wanting > to think in huge abstractions, non-timed environment etc., one might > need to play some with soldering irons and oscilloscopes first ;-) > > Perhaps at some level of (co?) design complexity, these things > (SystemC etc.) are really a necessity? On the other hand I've seen > software be ruined by too much complexity and/or overhead > in the languages, design and development processes, tools etc.. > > DJ > -- > >Article: 85942
27 years ago, I joined Zilog, and I found all those undocumented Z80 instruction codes, some of them quite useful. Being a good applications engineer, I started documenting them. But I was told in no uncertain terms that this was a bad thing to do, for it would commit Zilog (ad infinitum) to maintain the present peculiar decoding structure. "Don't unnecessarily limit our ability to make changes and improvements!" If it is documented to outsiders, it MUST be maintained and supported, no matter what kind of sweet promises the outsider makes. The moment we make even a small change, he will hate us, whether we kept him informed or not. If a user has an urgent need to know, and can convince us that it is meaningful to divulge data, we ususally are quite reasonable. But just: "I want to know" or "but Philips gave it to me" is not good enough. Peter AlfkeArticle: 85943
dp@tgi-sci.com wrote: <snip> > My question was not why I needed the data, it was why > Xilinx did not provide them - while I have been declaring all the time > that I needed no support, _nothing_ except the data they > _already_have_. If that is all you needed to know, you already have the answer : Why?: Because they can chose not to. -jgArticle: 85944
>Xilinx is still in the (C)PLD business. Philips isn't. Maybe >that's because Philips didn't make the right decisions on things >like this. Well, whatever you say. >If they give you the info and you can't understand >it or it's buggy or ..., then you will be even more pissed off at them >than you are now. So I won't use their products - just as I won't use them without the data. The only difference is in the case where I can use the data if they provide them. I am not asking them to advertise the data to all customers, I would sign an NDA and get the data perhaps only on paper etc. - trust me, I have thought of all these mainstream kind of arguments before asking. >If they give you the info, then the next guy who isn't so smart will >expect to get it too. And if he cannot use it so what? For I don't know which time repeated, I never asked for anything more but the data. If I cannot use it it is all my fault, just hand me the data they have used to write their tools. >How many $ do you spend on their chips? Less than the $9M/quarter they want to consider giving me the data. Obviously they know that the less hoops I have to jump through, the more of the designs I do for my and other companies would contain CPLDs. I am fairly resourseful as a design house, you know; and this can be seen on the web so they know that, too. >I'm not sure what you want to do. ... >> Here comes the question to the group: has anyone ever been >>successful getting fusemap data from Xilinx? (under NDA >>or whatever). Dimiter ------------------------------=AD=AD=AD----------------------------=AD-=AD-= ------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------=AD=AD=AD----------------------------=AD-=AD-= ------------Article: 85945
Valentin, what is your question? Clock Enable is very efficient in FPGAs. Being "free" must be the ultimate efficiency :-) Xilinx FPGAs always have a CE input that does not interfere with other logic, and is a synchronous input (really a multiplexer that makes the flip-flop either look at the new data, or at its own Q.) Peter Alfke, Xilinx Applications (from home)Article: 85946
Giovanni, I am a big fan of using BlockRAMs for "unusual" applications. But here is one warning: All Xilinx BlockRAM are synchronous devices, which means, changing the address input has no effect on the output, until you apply the right clock edge. While conventional static ROMs may not require a clock, the Virtex and Spartan BlockROMs do ( and I think the competition uses a similar structure). In most cases the clocked operation is no problem, in some cases it is a big advantage, and sometimes it is a pain... Peter Alfke, Xilinx ApplicationArticle: 85947
>If a user has an urgent need to know, and can convince us that it is >meaningful to divulge data, we ususally are quite reasonable. But just: >"I want to know" or "but Philips gave it to me" is not good enough. Well, rightly so. Remember, my posting was addressed to the group, not to Xilinx, simply because Xilinx refused to consider me for information before I made $9M quarterly revenue for them. I did explain why I needed the data then, here I go again - I use my own systems, my own design tools, my own JTAG access hardware, my own OS runing here etc., there is no mainstream PC involved in my design process. When I asked initially, I expected a reasonable answer like the one you just gave me - but I guess I had bad luck and landed perhaps not on the best place in your support department. The Philips support people were also cautious as I would expect them to be and I had to convince them I knew what I was doing, unfortunately this was not the case with the Xilinx support people. Dimiter ------------------------------=AD=AD=AD=AD---------------------------=AD-= =AD-=AD------------- Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------=AD=AD=AD=AD---------------------------=AD-= =AD-=AD-------------Article: 85948
Unfortunately xilinx dont't work :( I'm using last versione webpack (impact) 7.1i A question: but what's idcode? and where is idcode for xc9536xl Thanks againArticle: 85949
In an unrelated thread on FPGA<->CPU clock speeds, an FPGA developer stated that FPGAs are ill suited to replicating legacy CPU designs. I never got around to asking why, but a more relevant question is: What type of CPU architecture are FPGAs more suited to implement?
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