luke
/
prjxray
mirror of https://github.com/openXC7/prjxray.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

lib: xc7series: Handle the curious case of Type 0 packets 

Type 0 shouldn't exist but bitstreams generated with
BITSTREAM.GENERAL.DEBUGBITSTREAM=YES seem to use them as padding.

Signed-off-by: Rick Altherr <kc8apf@kc8apf.net>
Signed-off-by: Tim 'mithro' Ansell <mithro@mithis.com>
This commit is contained in:
Rick Altherr 2017-12-12 18:49:10 -08:00 committed by Tim 'mithro' Ansell
parent cfbfb477e6
commit 7345f2630a
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
lib/xilinx/xc7series/configuration_packet.cc
View File

@ -17,6 +17,14 @@ ConfigurationPacket::InitWithWords(absl::Span<uint32_t> words,
uint32_t header_type = bit_field_get(words[0], 31, 29); uint32_t header_type = bit_field_get(words[0], 31, 29);
switch (header_type) { switch (header_type) {
case 0x0:
// Type 0 is emitted at the end of a configuration row when
// BITSTREAM.GENERAL.DEBUGBITSTREAM is set to YES. These seem
// to be padding that are interepreted as NOPs. Since Type 0
// packets don't exist according to UG470 and they seem to be
// zero-filled, just consume the bytes without generating a
// packet.
return {words.subspan(1), {}};
case 0x1: { case 0x1: {
Opcode opcode = static_cast<Opcode>( Opcode opcode = static_cast<Opcode>(
bit_field_get(words[0], 28, 27)); bit_field_get(words[0], 28, 27));