| ... | ... | @@ -7,59 +7,34 @@ |
|
|
|
|
|
|
|
### Q: what is really the state of the design?
|
|
|
|
|
|
|
|
State in March 2013: The VME core has been tested in several
|
|
|
|
configurations, including on several different boards
|
|
|
|
([VFC](https://www.ohwr.org/project/fmc-vme-carrier/wiki) and
|
|
|
|
[SVEC](https://www.ohwr.org/project/svec/wiki)) together in the same
|
|
|
|
crate and with several other modules sending traffic at the same time.
|
|
|
|
Basically to test this core we used our experience that we had built up
|
|
|
|
when testing commercial VME boards. This also used DMA from the
|
|
|
|
processor board used in the crate.
|
|
|
|
|
|
|
|
The code has been developed by a company and then CERN had a student who
|
|
|
|
worked for a year on it. We still would like to do a serious review of
|
|
|
|
the code to make sure there are no hidden bugs and just to make it all a
|
|
|
|
bit cleaner.
|
|
|
|
It is a product that we will support as we will base all our SVEC
|
|
|
|
designs on it. For example the [ADC100M
|
|
|
|
mezzanine](https://www.ohwr.org/fmc-adc-100m14b4cha/wiki) that you sell
|
|
|
|
will also be ported to the
|
|
|
|
[SVEC](https://www.ohwr.org/project/svec/wiki) and will use the core.
|
|
|
|
Recently we found some errors and corrected them in a few days as can be
|
|
|
|
seen in the
|
|
|
|
[Repository](https://www.ohwr.org/project/vme64x-core/tree/master). This
|
|
|
|
was on Rev.194. From the commit comments in this same repository you can
|
|
|
|
also quite well follow what is being changed.
|
|
|
|
|
|
|
|
Resuming, yes it is a perfectly usable core:
|
|
|
|
|
|
|
|
- The black box testing we've done is a proof that it is working
|
|
|
|
pretty fine.
|
|
|
|
- CERN's commitment to use it for all SVEC designs assures it will
|
|
|
|
work and will be maintained in case we find any further bugs.
|
|
|
|
|
|
|
|
We will also be happy to receive feedback from you when you'll dig into
|
|
|
|
the code.
|
|
|
|
|
|
|
|
May 2017: the core is still used for any design using the SVEC. You may
|
|
|
|
follow any [outstanding
|
|
|
|
issues](https://www.ohwr.org/project/vme64x-core/issues) (that don't
|
|
|
|
stop us from using this core).
|
|
|
|
During October to December 2017, the core (version 2) was tested on a
|
|
|
|
SVEC card with the MEN A20 and MEN A25 masters.
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
## Technical
|
|
|
|
|
|
|
|
### Q: Does the core support RORA mode (Release on Register Access)?
|
|
|
|
### Q:How to port a design from v1.0 to v2.0?
|
|
|
|
|
|
|
|
The core does *not* support the RORA mode.
|
|
|
|
Furthermore note that the Interrupter implemented has not a queue.
|
|
|
|
You can implement a queue in your WB application and output a new
|
|
|
|
interrupt request only after a read operation.
|
|
|
|
This will be the equivalent of a RORA Interrupter.
|
|
|
|
The official top level entity for the vme64x core is xvme64x\_core,
|
|
|
|
which has the vme, wb and configuration grouped in
|
|
|
|
records.
|
|
|
|
|
|
|
|
The VME signals berr\_n and irq\_n are now active when set to '0' (like
|
|
|
|
on a VME bus), while in version 1.0 they followed the polarity of the
|
|
|
|
SVEC card.
|
|
|
|
|
|
|
|
The generic g\_WB\_GRANULARITY was added in v2.0. For compatibility, it
|
|
|
|
should be set to BYTE if the vme64x\_core is instantiated and to WORD if
|
|
|
|
the xvme64x\_core is instantiated.
|
|
|
|
|
|
|
|
For software compatibility, AM matching should be disabled by setting
|
|
|
|
generic g\_DECODE\_AM to false.
|
|
|
|
|
|
|
|
### Q:In which FPGA is it possible to fit the vme64x core?
|
|
|
|
|
|
|
|
On the SVEC card (Spartan 6), the core needs less than 750 registers.
|
|
|
|
|
|
|
|
We are testing the core in the following FPGA:
|
|
|
|
|
|
|
|
- Spartan 6
|
| ... | ... | @@ -80,24 +55,14 @@ It depends on your WB application. |
|
|
|
|
|
|
|
### Q: What are the VME address modifiers supported by the core?
|
|
|
|
|
|
|
|
Officially we support only:
|
|
|
|
|
|
|
|
- A24 and A32 with 32-bit data width, supervisor mode (0x09 and 0x39).
|
|
|
|
- Single, MBLT, BLT transfers.
|
|
|
|
- The A32 window has size of 0x1000000 and is fixed to Function 0.
|
|
|
|
- The A24 window's size is 0x80000 and it's attached to Function 1.
|
|
|
|
This is the default setup in `VME_CR_pack.vhd`.
|
|
|
|
|
|
|
|
Certain other modes (A16, unaligned/byte/halfword accesses) are
|
|
|
|
implemented in the VHDL but have not been fully
|
|
|
|
tested.
|
|
|
|
- A24: AM 0x38 to 0x3f
|
|
|
|
- A32: AM 0x08 to 0x0f
|
|
|
|
- CS/CSR: AM
|
|
|
|
0x2f
|
|
|
|
|
|
|
|
### Q: I use the SVEC. How can I change the base address by writing appropriate values in some registers (ADER, ADEM, and possibly others)?
|
|
|
|
|
|
|
|
Probably the example in the documentation of the
|
|
|
|
[VME64xCore](https://www.ohwr.org/project/vme64x-core/commits/master/documentation/user_guides/vme64x_user_manual.pdf)
|
|
|
|
of the SVEC is the most helpful in this, as it contains worked
|
|
|
|
examples.
|
|
|
|
Write the ADER registers with the address base and the AM.
|
|
|
|
In addition, the code of [svec\_setup\_csr() in the svec device
|
|
|
|
driver](https://www.ohwr.org/project/svec-sw/tree/master/) can also be
|
|
|
|
very helpful in understanding how you can do the configuration by
|
| ... | ... | |
