FPGA Central

Why is this the case even when a single Aurora transmitter or a single
receiver is chosen? This seems to be wasting precious resources... How can I
utilize all the available GT11 blocks?

Thanks,
/Mikhail

Hi,

In Virtex-4 silicon, the transceivers exist in pairs and they share some
common circuits (such as the dynamic reconfiguration port and clocking
circuits). It is perfectly legal to combine two one-lane designs (using two
GT11) into a single tile as long as you follow the rules in the user guide.

The architecture wizard is fairly generic, and when writing out code, will
write GT11 in pairs. If you select a one-lane configuration, you will get
one GT11 that is actively used, and another GT11 that is just along for the
ride. The architecture wizard doesn't know enough about your specific
design requirements to determine if transceivers can be shared or not.
However, you can easily take the architecture wizard output and create a
shared tile by copy/paste as long as you are not violating the rules in the
user guide.

With this approach, for example, you could creat a single tile that used two
GT11 transceivers to implement two independent one-lane PCI Express
interfaces.

Eric

Thanks for your help Eric. I think this explanation should find its way into
the documentation.

I am trying to create a very simple data loopback test design. The only
examples that I could find require using EDK, and are written in Verilog. I
would like to avoid using the former at this point as it would distract my
attention from the RocketIO stuff and for a number of reasons I need to use
VHDL. So far I have created a single Aurora transmitter and a basic
testbench that uses a 32-bit wide counter to supply data to the transmitter.
The simulation seems to show that my design is alive, but I am yet to
interpret properly what I see...

I am having difficulty in figuring out what to do with all the ports that
the Architecture Wizard chose to expose. In my opinion there are way too
many. Why, for example, the dynamic configuration bus is exposed at all? I
think this should be an option... Do I really need to bother about things
such as Running Disparity Control, all the CRC stuff, etc. to be able to do
basic data loopback? And why do I see RX side clocks in a transmitter only
component? Are they there "along for the ride" similarly to the second
transceiver?

Thanks,
/Mikhail



"Eric Crabill" <[email protected]> wrote in message
news:[email protected]
> Hi,
>
> In Virtex-4 silicon, the transceivers exist in pairs and they share some
> common circuits (such as the dynamic reconfiguration port and clocking
> circuits). It is perfectly legal to combine two one-lane designs (using
two
> GT11) into a single tile as long as you follow the rules in the user
guide.
>
> The architecture wizard is fairly generic, and when writing out code, will
> write GT11 in pairs. If you select a one-lane configuration, you will get
> one GT11 that is actively used, and another GT11 that is just along for
the
> ride. The architecture wizard doesn't know enough about your specific
> design requirements to determine if transceivers can be shared or not.
> However, you can easily take the architecture wizard output and create a
> shared tile by copy/paste as long as you are not violating the rules in
the
> user guide.
>
> With this approach, for example, you could creat a single tile that used
two
> GT11 transceivers to implement two independent one-lane PCI Express
> interfaces.
>
> Eric
>
>

Hello,

I passed your comments on to those working on the architecture wizard for
RocketIO. Based on your comment, I suggested that they consider not only
"1-lane" and "2-lane", but "dual 1-lane" as valid configurations for
architecture wizard generated output. I also suggested that they add an
option for, "I don't want CRC block functions, please hide those ports from
me..." which would cause them to be tied off inside the module instead of
brought to ports.

Having used the architecture wizard for x1 and x4 PCI Express designs, I can
appreciate your comment on the number of ports. There are a lot, but then
the block has a great deal of capability. Feedback like yours will drive
the addition of options to make the resulting architecture wizard modules
easier to use in cases where not all the capability is needed.

Yes, what you've got right now for a single lane, transmit only function
certainly seems like a lot of extra ports! The best I can offer you
currently is to sit with the user guide and go through the module's input
ports one at a time, determining what value to assign to either deassert
them or leave them in a benign state. It is tedioius but not too hard
(having done it myself...) If you have specific questions about how to tie
a given port, the Xilinx customer applications hotline is the best place to
get them answered.

Eric

Eric,

> I passed your comments on to those working on the architecture wizard for
> RocketIO. Based on your comment, I suggested that they consider not only
> "1-lane" and "2-lane", but "dual 1-lane" as valid configurations for
> architecture wizard generated output.

Thanks for passing my comments. The wizard actually doesn't use the concept
of lanes. I think I have seen it in some earlier version, but I am not sure.
It does ask how many tranceievers to bond but only if the Receiver is
enabled on the first page.

> I also suggested that they add an
> option for, "I don't want CRC block functions, please hide those ports
from
> me..." which would cause them to be tied off inside the module instead of
> brought to ports.

I think there has to be a mode where the generated module has only a
parallel data bus input/output, a clock and the serial output/input and
perhaps a few status signals. Everything else has to be optional and grouped
according to the functionality.

> Yes, what you've got right now for a single lane, transmit only function
> certainly seems like a lot of extra ports! The best I can offer you
> currently is to sit with the user guide and go through the module's input
> ports one at a time, determining what value to assign to either deassert
> them or leave them in a benign state. It is tedioius but not too hard
> (having done it myself...)

That's what I am doing, but the manual is not always clear and many of the
pins require deep understanding of the MGBT operation. For example, the port
I am currently looking at is the ENMCOMMAALIGN. Here is what the RocketIO
manual says about it:

"Selects realignment of incoming serial bitstream on minuscomma. When set to
logic 1, realigns serial bitstream byte boundary to where minus-comma is
detected."

The Aurora manual does not mention the ENMCOMMAALIGN, although "Enable comma
alignment" can be found in some of the state diagrams. But which mode?
According to the Table 3-6 in the RocketIO manual (ug076) there are at least
3 different enable modes. This is all very confusing. If Aurora requires
this to be set in any way, then obviously it has to be done by the wizard.

Thanks,
/Mikhail