VME64x core issueshttps://ohwr.org/project/vme64x-core/issues2019-02-12T09:03:35Zhttps://ohwr.org/project/vme64x-core/issues/25IO registers for VME2019-02-12T09:03:35ZPablo AlvarezIO registers for VMEThe VME signals (AS, DS, ADD..) should be registered in VME64xCore\_Top
and not in VME\_bus and IRQ\_controller.Davide PedrettiDavide Pedrettihttps://ohwr.org/project/vme64x-core/issues/23strange behavior during BLT accesses2019-02-12T09:03:33ZDavide Pedrettistrange behavior during BLT accessesSingle access modes working fine in both the VFC and SVEC boards,
plugged in each slot.
BLT and MBLT test on the **VFC** board:
- Slot 8: Ok
- Other slots: sometimes the test fails
BLT and MBLT test on the **SVEC** board:
Sometimes the test fails in all the slots.
The probability that the test fails, it increases if the board (both VFC
and SVEC) is plugged in a slot near the slot 1.
The VME is an asynchronous protocol so the behavior must be the same in
all the slot. Is not it?
Using the same vme64x core and the slot 8, the BLT test fails on the
SVEC and it is ok on the VFC. Why?https://ohwr.org/project/vme64x-core/issues/21Several bugs: race condition ad.decoder, reset handling, IRQ controller2019-02-12T09:03:31ZErik van der BijSeveral bugs: race condition ad.decoder, reset handling, IRQ controllerFixed several bugs: race condition on address decoding (the CTR
interrupt issue), invalid reset handling in CROM init sequence & strange
combinatorial loop in VME\_IRQ\_Controller.
-----
Bugs handled on 7 March 2013 in
[Revision 194](https://www.ohwr.org/project/vme64x-core/tree/194/)
Created issue to keep track.Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/vme64x-core/issues/17Interrupter hangs with multiple SVECs2019-02-12T09:03:28ZTomasz WlostowskiInterrupter hangs with multiple SVECsIf an IRQ comes at the same moment from more than 1 SVEC, the 1st card
in the daisy chain stops handling IRQs.
Fixed in commit \#8006dbda.Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/vme64x-core/issues/16multiple cards DTACKing on same CSR address2019-02-12T09:03:28ZTomasz Wlostowskimultiple cards DTACKing on same CSR address1\. Write to CR/CSR of card A (write is OK, dtacked only by A)
2\. Write to CR/CSR of card B (both A and B will DTACK that access).Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/vme64x-core/issues/13Incorrect WB error handling2019-02-12T09:03:25ZTomasz WlostowskiIncorrect WB error handlingIn case of a wishbone bus error (due to unmapped address), the core
generates a VME bus error on the cycle after the wrongly addressed one
(@myself: look at the handling of s\_wberr1 signal in VME\_bus)Tristan GingoldTristan Gingoldhttps://ohwr.org/project/vme64x-core/issues/12Incorrect value for CR/CSR space specification ID2019-02-12T09:03:25ZDimitris LampridisIncorrect value for CR/CSR space specification IDAccording to ANSI/VITA 1.1-1997, section 10.2.1.1, the CR/CSR space
specification ID should be equal to 2 for VME64x.
Attached a small git patch against current master branch to amend this.
### Files
* [0001-hdl-CR-CSR-space-specification-ID-should-be-equal-to.patch](/uploads/a83d357b690d5a5dde3a7ad3bb4a6fd0/0001-hdl-CR-CSR-space-specification-ID-should-be-equal-to.patch)Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/vme64x-core/issues/11Incorrect value for CR/CSR space DAWPR2019-02-12T09:03:24ZDimitris LampridisIncorrect value for CR/CSR space DAWPRAccording to ANSI/VITA 1.1-1997, section 10.2.1.4.1, Table 10-3, the
CR/CSR space DAWPR values should be equal to 0x84 when a function
accepts D32, D16 or D08(EO) cycles.
0x86 (the currently used DAWPR value) is reserved for future use.
Attached a small git patch against current master branch to amend this.
### Files
* [0001-hdl-CR-CSR-space-DAWPR-values-should-be-equal-to-0x8.patch](/uploads/72fc2c0fe2bfaa971a5c0bc32336a3fd/0001-hdl-CR-CSR-space-DAWPR-values-should-be-equal-to-0x8.patch)Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/vme64x-core/issues/10Custom CSR registers make use of reserved area2019-02-12T09:03:23ZDimitris LampridisCustom CSR registers make use of reserved areaThe following additional CSR registers of the VME64x core (not part of
the standard) are implemented in an area reserved by the ANSI/VITA
1.1-1997 for future use.
<table>
<tbody>
<tr class="odd">
<td>IRQ_Vector</td>
<td>0x07FF5F</td>
</tr>
<tr class="even">
<td>IRQ_level</td>
<td>0x07FF5B</td>
</tr>
<tr class="odd">
<td>MBLT_Endian</td>
<td>0x07FF53</td>
</tr>
<tr class="even">
<td>TIME0</td>
<td>0X07FF4F</td>
</tr>
<tr class="odd">
<td>TIME1</td>
<td>0X07FF4b</td>
</tr>
<tr class="even">
<td>TIME2</td>
<td>0x07FF47</td>
</tr>
<tr class="odd">
<td>TIME3</td>
<td>0x07FF43</td>
</tr>
<tr class="even">
<td>TIME4</td>
<td>0x07FF3F</td>
</tr>
<tr class="odd">
<td>BYTES0</td>
<td>0x07FF3b</td>
</tr>
<tr class="even">
<td>BYTES1</td>
<td>0x07FF37</td>
</tr>
<tr class="odd">
<td>WB32bits</td>
<td>0x07FF33</td>
</tr>
</tbody>
</table>
These are documented in Section 2.1 of the VME64x user manual (Table 1).
According to the standard, Table 10-13, the region \[0x7FC00..0x7FF5F\]
within the "Defined CSR Area" is reserved and should always read zero
(rules 10.13 and 10.14 in section 10.2.2).
Instead the standard provides the "User CSR Area" for design-specific
registers (section 10.2.5), which the VME64x core should use for the
registers listed above.Tom LevensTom Levenshttps://ohwr.org/project/vme64x-core/issues/6Dynamic Function Sizing mis-implemented2019-02-12T09:03:21ZDimitris LampridisDynamic Function Sizing mis-implementedThe DFS bit in position 2 of the ADEM is meant for functions that do not
have a fixed size (mask bits in ADEM). When DFS bit is enabled, then the
master can use the DFSR bit in the respective ADER to dynamically load a
new bit mask using the C bits of the ADER. After this is done, the
master should restore the original contents of the ADER, in order to
allow address matching. This is explained in Tables 10-4 and 10-8 of the
ANSI/VITA 1.1-1997 standard.
Our current implementation does something completely wrong: it
interprets the DFS bit as a flag to enable the checking of the used AM
against the the AM declared in the ADER. This is turn leads to another
bug, described in issue \#1407.
For now, this is a low priority bug, since the DFS bit is hard-coded to
zero and there is no possibility for the user to enable DFS mode (see
also \#943). However, once the CR space (see also issues \#767 and
\#791), this bug will have to be fixed.Tom LevensTom Levenshttps://ohwr.org/project/vme64x-core/issues/5Extra Function Decoders not supported2019-02-12T09:03:20ZDimitris LampridisExtra Function Decoders not supportedthe EFD bit of the ADEM allows for multiple function decoders per
function. Currently the VME64x core does not respect this bit, not does
it document the fact that it does not support it.
For now, this is a low priority bug, since the EFD bit is hard-coded to
zero and there is no possibility for the user to enable EFD. However,
once the CR space (see also issues \#767 and \#791) is made configurable
through generics, this bug will have to be fixed.Tristan GingoldTristan Gingold