[partial-reconfig] JBits, Anyone?

["Umar Mushtaq" <misfit_05@xxxxxxxxxxx>]

I've been tinkering around with it for a couple of weeks, and to give
credit where its due, it does bring back memories of the Java course I
took in 2001-2002... : ) ...

On a more serious note, it appears to me that its strength lies mainly
in its ability to access really low level resources ( correct me if I'm
wrong because I am after all new to JBits ) ... what I fail to
understand is its usefulness for someone working on a complex design...
going down all the way to the LUT level would hardly be appealing... the
more complex the design, the more the designer would like to visualize
it as made up of large, interconnected blocks... 

The work I'm doing mainly follows the modular design thingie... so I've
got partial bitstreams for the modules and full ones for every
combination... what I would like to do with JBits is to swap
configurations, and that seems easy enough to do... The details of the
JBits class say that if you re-read a file to a JBits object, it only
overwrites the packets ( or bits or whatever ) which differ from the
original bitstream, and when there is a call to write () ... ( a call
after the very first call to write that is, so you have to make sure you
make a call to write () , or generate () or generateBitstream () , to
get the full bitstream write out of the way ) ... only the overwritten
stuff is written out... that would in effect produce a bitstream a
bitgen -r would produce... 

For instance... 

**********

jbits.read ( "bitstream1.bit" ) ; // Reads original bitstream to JBits
object jbits...
jbits.read ( "bitstream2.bit" ) ; // Reads second bitstream, and
overwrites the parts that don't match...

byte [ ] garbage = jbits.generate (JBits.FULL ) ; // Get the Full
bitstream out of the way, send it to a byte array you won't use...

.
.
.

( make calls to methods that enable CRC and force the device to remain
on ... ) 

.
.
.


jbits.writePARTIAL( "bitstream3.bit" ) ; // Optionally use generate ()
to generate a byte array or generateBitstream () ...

**********

I might've got the syntax slightly wrong, but you get the idea... 

What I'm wondering is, shouldn't this be enough for someone working with
modular design, or a design which is sufficiently complex to make the
drop to CLB level unappealing? Or is there more to it that I don't see
at the moment?

Also, has anyone tried overwritting the first bitstream with a partial
module bitstream, and then compared the new bitstream with the full
bitstream that has the module anyway...

For instance, say you've got three modules, one of which is
reconfigurable and has two configurations ( a la xapp290 ) ... you read
the full bitstream1, which has one instantiation of the module, and then
overwrite it with the partial bitstream of the second configuration of
that module, to get a new bitstream... in the first call to write, the
entire new bitstream should be written out, with the portions that are
unchanged... this new bitstream should match ( shouldn't it? ) the full
bitstream2, which featured the second configuration of the
reconfigurable module... 

I've tried to do this by reading the JBits objects into Bitstream ( )
objects and also byte arrays and then comparing them... I can't say I've
had much success in viewing the comparisons on the screen... the .get (
int i ) method for the Bitstream objects reads the packet, but all
corresponding packets appear the same on two different bitstreams... the
same goes for the byte array, with the additional problem that all byte
arrays seem to end up with identical contents, no matter which .bit file
was originally read...

Long post, but I hope others will chime in with their experiences...

: )

Sincerely,
Umar
-- 
  Umar Mushtaq
  misfit_05@fastmail.fm

___________________________
partial-reconfig mailing list
partial-reconfig@itee.uq.edu.au
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/partial-reconfig/