Re: Question on Virtex-4 CLB


There are companies who use our parts to verify the logic prior to its
placement in an ASIC. Good business, as they buy our largest parts, and
lots and lots of them.

We make no further effort to help them create ASICs. We appreciate
their use of our parts, even if that use leads eventually to less
business.

I did not know this. Perhaps this is an area that Xilinx should look into.
Clearly in the future, the automation of ASIC design and manufacturing will
dramatically drop and engineers will be looking to ASICs for very small
production runs and they will want a seemless migration path.

On the other hand, since what we do we consider proprietary, we are not
going to share schematics with you.

I understand the importance of proprietary intellectual property, as a
patent owner, better than most. However, it seems that keeping your
customers in the dark about what they are programming is
counterproductive.
What are Xilinx's real risks? And have they been ripped off in the past?

Then you can appreciate that customers have trust in Xilinx not to do
anything to make it trivial, or easy, for their clever IP to be ripped
off.

I think what we were talking about was the physical aspects of the Xilinx
fabric to give engineers the ability to think clearly about what is or could
be. Size and shape would be helpfull. I don't suggest that you give away
your schematics if you believe that another manufacturer might copy them
although I doubt that would happen.

If it would help, I can document an example of how the lack of information
about the V4 ISERDES has increased my project length by about two months. If
anyone at Xilinx is interested in what I have to say that is.

As for being ripped off in the past, we have not been harmed per se, but
customers have been harmed by a company cloning an entire pcb, and then
copying the eproms, and selling that product for less money. I won't
say who did this, as it is all litigated and settled now, and Xilinx
derives benefit because both companies bought our FPGAs (the cloning
company had to, as they had no means to modify or change the design, or
even to fix any bugs).

This is why today we offer the bitstream decryption features in V2,
V2Pro, V2Pro-X, V4, and now V5. We will do whatever we can to help
protect the customer's investment.

What you refer to as "Keeping our customer's in the dark" is in no way a
hindrance, or a handicap,

For example, I look at this slicem and slicel pattern on the editor. I have
no historical perspective of how this configuration came about, why they are
placed as they are, nor do I have any sense of their real size. I also can
not determine what logic they are performing through the editor. All I can
do is trace back my signals to the VHDL and guess what the synthesizer has
done. It's a big guessing game. How in the dark do you think I am?

as reverse engineering is perfectly legal to
fix a problem, or discover how something works.

Most engineers do not want to reverse engineer anything. It's time consuming
and not to their immedate goals.

We do not keep our
customer's in the dark for a legitimate reason.

If someone has to reverse engineer something (for example: a soft error
broke their design, which line of VHDL did that bit affect?) we are
happy to work with them to resolve the issue by telling them exactly
what they need to know (in fact, we will parse their design, and use our
tools to discover what they require).

I found that the comp.arch.fpga has been far more helpful than anything
Xilinx has done. A while ago I went through the process of putting in a
case about one of the GUIs that generates BRAM coeffcients and that the GUI
bombs with more than 16 or so coefficients. I spent more than a day
discovering, isolating and documenting the issue. The engineer told me that
the problem would get fixed, but, I never got word back that it did. I feel
that the my efforts in reporting this problem are undervalued.

You know I picked Xilinx for three reasons over Altera. First, I called
Altera support, and could not speak to an engineer, whereas, I was able to
speak to someone at Xilinx. Second, the distributors Avnet had a free
beginners class and were very helpful. Third, this comp.arch.fpga seemed
fairly open and helpful to newcomers.

I suggest that Xilinx open up its engineering even further than it has if it
wishes to remain the FPGA leader.

Brad Smallridge
aivision
dot com



.

Relevant Pages

  • Re: Questions
    ... If I discover that more ... Hotline engineers are required to close with their customers: ... Thank you for choosing Xilinx, as we recognize you do have other choices. ...
    (comp.arch.fpga)
  • Re: for all those who believe in ASICs....
    ... The business case for in-house fab, or fabless, has ... they were one of the most vocal camps against fabless ... There are ASICs (with their well-known technical advantages and ... The fairy land here, is that Xilinx ...
    (comp.arch.fpga)
  • Re: Spartan 3 documentation confusing...
    ... I can speak from personal experience: When I arrived at Xilinx in 1988 ... I disagree with the statement that engineers cannot write, ... The tech writers know their grammar and spelling, ... but they usually have never been working engineers. ...
    (comp.arch.fpga)
  • Re: initializing array of registers
    ... more of a Xilinx tools (XST) question. ... That's really strange, because comp.arch.fpga is infested with Xilinx application engineers. ... but you might find that the Lattice Semiconductor engineers are a lot more helpful than the Xilinx people. ...
    (comp.lang.verilog)
  • Re:
    ... I try to adapt my phraseology to match the IQ of my target audience. ... In the case of Xilinx application engineers I'm forced to constrain my vocabulary to simple words understandable by simple minds. ...
    (comp.arch.fpga)