Re: [casper] PlanAhead to a working bof

[Jack Hickish]

There's also a UCF yellow block that lets you add ucf files to your design
(much like the PCORE yellow block). I think there's also a method to inject
ucf constraints via an environment variable (I think you could find this in
the git log somewhere).

Cheers,
Jack

On Wed, 3 Feb 2016 at 10:31 David MacMahon 
wrote:

> Hi, Johnathon,
>
> On Feb 3, 2016, at 2:26 AM, Gard, Johnathon D. 
> wrote:
>
> There are options in the PlanAhead bitfile generation and I could have
> those wrong. This could be very likely.
>
>
> The bitgen options that the CASPER flow uses are in
> mlib_devel/xps_base/XPS_ROACH2_base/etc/bitgen.ut.
>
> 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.
>
>
> Newer versions of mlib_devel support the inclusion of user-specified UCF
> snippets into the overall UCF file.  To do this, you create a
> “/ucf” directory and then place files with a “.ucf” extension
> into that directory.  All .ucf files in that directory will be included in
> the overall system.ucf file that the casper flow generates.
>
> For example, if your model is "/path/to/my_model.slx", then all *.ucf
> files in “/path/to/my_model/ucf/” will be automatically included in the
> system.ucf constraints file.
>
> HTH,
> Dave
>
>

Re: [casper] PlanAhead to a working bof

[David MacMahon]

Hi, Johnathon,

> On Feb 3, 2016, at 2:26 AM, Gard, Johnathon D.  
> wrote:
> 
> There are options in the PlanAhead bitfile generation and I could have those 
> wrong. This could be very likely. 

The bitgen options that the CASPER flow uses are in 
mlib_devel/xps_base/XPS_ROACH2_base/etc/bitgen.ut.

> 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. 

Newer versions of mlib_devel support the inclusion of user-specified UCF 
snippets into the overall UCF file.  To do this, you create a 
“/ucf” directory and then place files with a “.ucf” extension into 
that directory.  All .ucf files in that directory will be included in the 
overall system.ucf file that the casper flow generates.

For example, if your model is "/path/to/my_model.slx", then all *.ucf files in 
“/path/to/my_model/ucf/” will be automatically included in the system.ucf 
constraints file.

HTH,
Dave

Re: [casper] PlanAhead to a working bof

[Gard, Johnathon D.]

Thanks Jack and David


Both of those are what I am looking for. The PlanAhead output a .bin not .bit 
and the ucf file yellow block.


One other question that has come up while looking at the ucf file is that 
xilinx by default groups all of the clocks in the design into one clock group. 
This seems to imply that all of the clocks have a synchronous relationship 
which is not true. In our case, we are running the MKID DAC/ADC board which 
provides the external clock to the FPGA and that is what we are running the 
FPGA core clock off of. Have you tried to change this relationship and break 
the clock domains up into truly different asynchronous clock groups? I am also 
concerned that the clock group is the only timing constraint present in the 
file. I am hoping that someone may have a more functional timing constraint 
file with realistic timing constraints.


For the yellow block you are talking about I may have to merge some changes 
over because that block is not present in the mlib-devel I have been working 
with.

The git I have been working from is 
http://github.com/casper-astro/mlib_devel.git from a little over a year ago.

I will look into a more updated github repo that people have been working with.

Johnathon Gard
NIST

[casper] PlanAhead to a working bof

[Gard, Johnathon D.]

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 = 
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