Hi Johnathon,

What incantation are you using with mkbof? I believe what you want is:

mkbof_64 -o output.bof -s core_info.tab -t 3 top.bin

Note you want a .bin rather than a .bit file -- I believe this is an option
in bitgen (maybe it automatically happens in planahead).

Jack


On Wed, 3 Feb 2016, 2:27 a.m. Gard, Johnathon D. <johnathon.g...@nist.gov>
wrote:

> Hello Casperites,
>
>
>
> ROACH2, MATLAB 2012a (I think), ISE 14.7, Ubuntu 14.04 LTS
>
>
> I am working on compiling firmware without timing errors. More like
> ignoring static configuration register timing errors. Any rate, I have been
> pulling my design into PlanAhead successfully and applying some DSP slice
> constraints with some success. When it comes time to generating a bof file,
> I used the mkbof_64 executable located in the implementation directory that
> simulink creates. This seems to work fine. The problem arises when I move
> the generated bof file to my ROACH2 and try to program the FPGA. I upload
> the bof via python and call the progdev() command through python. This
> fails without anything meaningful in python. However when watching the
> serial output from the PPC, I get this:
>
>
> /usr/bof # roach open config called
> rdev gpio preconfig doneProgrammed fpga device id = ffffffff
> Attempted to program incorrect configuration onto Virtex6 FPGAroach
> release config called
>
>
> I am not sure what might be happening here. I was wondering if anyone else
> had tried this or ran into such a problem before.
>
>
> Other notes and ideas:
>
> I could be using the wrong mkbof, but when a design meets timing the
> casper_xps gui script makes a bof that works. So, maybe the script uses a
> different mkbof_64.
>
>
> There is another mkbof executable, but that one does not seem to function.
> I am assuming it is the 32 bit version, which would mean I would need a
> bunch of 32 bit libraries.
>
>
> There are options in the PlanAhead bitfile generation and I could have
> those wrong. This could be very likely.
>
>
> I  could alternatively use the system.ucf file updated by PlanAhead
> through the casper_xps process in matlab. However this would drop my
> control of the PAR which seems to have a strong influence on how well it
> meets timing. Ironically, timing driven placement gets the far worse timing
> results.
>
>
> As far as what it running on the PPC and what katcp library I am using,
> That is a very good question which I truly don't know the answer to.
>
>
> Any other ideas or solutions?
>
>
> Johnathon Gard
>
> National Institute of Standards and Technology
>
>
>
>

Reply via email to