Question on Virtex-4 CLB

If I look in the FPGA editor there seems to be one element in the CLB of a Virtex-4 that is odd as compared to previous FPGA generations that I have looked at in the FPGA editor.

The CLB looks something like this in ASCII art:

+-------------+ | | +--+ | | | | | | | | +-----+ | | | | |SLICE| | | | | | | | | | | +-----+ | | | | | | | | +-----+ | | | | |SLICE| | | | | | | | | |??| +-----+ | Switchbox | |??| | | | | +-----+ | | | | |SLICE| | | | | | | | | | | +-----+ | | | | | | | | +-----+ | | | | |SLICE| | | | | | | | | | | +-----+ | | | | | | +--+ +-------------+

The box with question marks just seems to rearrange the wires so that they are grouped according to function at the switchbox. Is that all there is to it?

/Andreas

Reply to
Andreas Ehliar
Loading thread data ...

Andreas,

I would like to educate the newsgroup: FPGA_editor has a highly simplified graphical visual representation of the chip that is the 'software view' of the world -- it has very little basis in the actual hardware.

I often have people ask me questions about the editor view, only to have to remind them that it does not represent the schematics.

For example, there is no such thing as a "switchbox." It doesn't even exist.

That said, improvements or changes in FPGA_editor may be done for reasons having nothing to do with the actual architecture, or hardware. Or they may be a way to represent a new architectural or hardware feature in a simplified fashion.

Aust> If I look in the FPGA editor there seems to be one element

Reply to
Austin Lesea

I wrote down a similar question about some skinny rectangles on the perimeter of a SX35. These seem to connect to the connecting wires and have the funny names OMUX, DOUBLE, and HUNIHEX. Any idea about what these are?

If the editor does not show us the reality of the physical spaces in the silicon as Austin has suggested that's fine with me. I can speculate on how some features might be too small to show graphically.

However, where can one find out about the real sizes of the fabric? Curious minds will want to know if they are planning future ASIC designs or might want to suggest to Xilinx some future designs.

Brad Smallridge aivision dot com

Reply to
Brad Smallridge

Brad,

Of course, we are not interested in helping anyone design an ASIC, so you are unlikely to get much in the way of support there.

As for suggesting what you would like in future FPGAs, we are (of course) always open to suggestions.

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

Aust> I wrote down a similar question about

Reply to
Austin Lesea

Hmm. I thought that most fpga manufacturers provide a path from fpga to ASIC. Is this not true of Xilinx?

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?

Brad Smallridge aivision

Reply to
Brad Smallridge

Brad,

Good questions.

I will attempt answering them,

-snip-

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.

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.

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, as reverse engineering is perfectly legal to fix a problem, or discover how something works. 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).

Austin

Reply to
Austin Lesea

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.

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.

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?

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

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

Reply to
Brad Smallridge

I really don't know. In my good old Atmel days, the express busses were terminated inside a cell somehow.

There seems to be a V shape connection between pairs that can be seen by double clicking inside the skinny box, or a cryptic post-place error if you click on the lines, but again, I'm in the dark.

Brad Smallridge

Reply to
Brad Smallridge

As a user of comp.arch.fpga I (of course) find it very useful. But one thing which is not immediately obvious is that comp.arch.fpga is probably quite useful even to users who have never heard of Usenet. This is because a user who searches for an FPGA related question on google often find an archived message from comp.arch.fpga. (Even if they don't specifically search on google groups.)

Regarding academic users: Academic users tend to become commercial users when they graduate and start working.

/Andreas

Reply to
Andreas Ehliar

Andreas,

Understood. Good points. That is also why Xilinx has a very active and committed University Program,

Aust> >> We (Xilinx) do not know how useful comp.arch.fpga really is.

Reply to
Austin Lesea

array?

You could either leave them hanging/floating or direct them back into the array. A routing U-turn, so to speak.

That connection is the "U-turn".

Eric

Reply to
Eric Crabill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.