Hi Xavier,

On Thu, 7 Mar 2019 at 15:56, Xavier Bosch <[email protected]>
wrote:

> Hi everyone,
>
> I have a SNAP + Rpi3 board with a 410T FPGA instead of a 160T
>
> TL;DR: When I do fpga.listdev() I get the correct list of registers but
> when I try to read or write the registers I always get an error, no matter
> what I do. I suspect that the RPi parses the BOF and gets the right memory
> mapping but the FPGA refuses to be programmed for some reason.
>

You are almost certainly correct - I doubt the FPGA is getting programmed.

The raspberry pi JTAG code was hard-coded for the SNAP 160T. The program
call is here
https://github.com/jack-h/katcp_devel/blob/b5edeb8f4fcdb38aa413e12ee8dceddde2b35c36/tcpborphserver3/upload.c#L250
and at the very least I think you'll have to change the binary size at
https://github.com/jack-h/katcp_devel/blob/b5edeb8f4fcdb38aa413e12ee8dceddde2b35c36/tcpborphserver3/rpjtag_bit_reader.h#L20
you may find that there are other hardcoded IDs floating around.

Not that the rpi-devel-casperfpga version in this repo will only work with
casperfpga and .fpg files. The rpi-devel branch will only work with bof
files and some (probably now deprecated) version of the katcp client. I
would recommend using the casperfpga version.

Also make sure that you're using a very short ribbon cable between the Pi
and SNAP. Preferably <6 inches. If things begin sort of working, you should
see the DS3 "FPGA_DONE" LED go out when you start programming, and come
back on when programming is finished. It sounds like the Pi is not even
deprogramming the original bit stream, never mind programming a new one.



>
> ==  More information ==
> When I turn on the board an LED blinks
>

This is probably the golden image burned at the factory(?)


>
> To use the 410T FPGA I had to do some modifications to the mlib_devel
> libraries:
>
>    - updated the yellow block,
>    - updated the platforms/snap.yml, (I have only commented the xc7k160t
>    line and remove the comment on the xc7k410t line, not sure if more changes
>    are required. The hypothesis is that both FPGAs are identical pin by pin.)
>
>
That should be all you need to do.


>
>    -
>    - updated the /hdl_sources/xadc/xadc_wiz0.xci
>    - some other minor updates to .m files
>
>
I'd be interested in knowing what these are - if they're backwards
compatible they should be merged in.


> After some struggle, I got it to compile a very simple design similar to
> SNAP Tutorial #1 in readthedocs.io: sys_clk (no external clock provided)
> + adder with 32 bit read/write registers.  No microblaze controller. The
> compilation successfully ends and I get the .fpg and .bof files
>

It's worth noting also that the programming functionality of the SNAP's
microblaze controller might also be funky owing to different bitstream
sizes.


>
> I got a Rpi3 + Golden image downloaded from the CASPER website and I
> connected to the SNAP board.
> With a Linux machine I installed corr and fpgacasper Python packages
> successfully.
> Then I send the generated BOF file to the Rpi, using several techniques
> following the CASPER website tutorials (SNAP bringup page) such as SCP +
> fpga.progdev() I get an immediate OK in the ipython console. I have also
> tried to straight programing the FPGA using telnet at 7147 port and the
> "?upload 3000" command, this takes a little more of time but is quite
> fast,then I get the message:
>
> log info 1524086331554 raw
> attempting\_to\_program\_bitstream\_of\_15877916\_bytes\_to\_device\_/dev/shm/fpga-config
> #fpga loaded
> #log warn 1524086331609 raw
> map\_request\_0x20000\_is\_within\_limit\_0x8000000
> #fpga mapped
> #fpga ready
>

I'd suggest, after changing the rpi code, you program an fpg file using
CasperFpga.upload_to_ram_and_program(`fpg file path`). Or (even better)
begin by testing code running on the PI which directly calls the underlying
rpijtag routines. The tcpborphserver wrapping adds a fair amount of
misdirection to the whole process.


>
> I also tried different SW1 configurations such as  2 and 5 at "1" and 2
> and 5 at "0 with no difference. SNAP bringup page specifies the position of
> the switches when using JTAG so I am not sure how they should be otherwise.
> I also tried to use the .fpg file as instructed in SNAP Tutorial #. After
> programming SNAP keeps blinking the same LED as before, no matter what I do
> in the SLX design.
>
> Then, when I do fpga.listdev() I get the correct list of registers but
> when I try to read or write I always get an error, no matter what I do. I
> suspect that the RPi parses the BOF and gets the right memory mapping but
> the FPGA refuses to be programmed for some reason.
>

I suspect the programming fails, but tcpborphserver (running on the Pi)
thinks everything is fine and happily returns the meta-data it found in the
fpg file when you call listdev. But actually the board isn't really
programmed, so anything you try to do to talk to it fails.


>
> Has anyone worked with a SNAP 410T? any similar experience? am I missing
> anything?
>

I'm fairly certain you have the only 410T version of SNAP on the planet :)
Happy to help if I can, but obviously I don't have any hardware to play
with....

Cheers
Jack


>
> Any help will be welcomed,
> Thank you!
> Xavi
>
> --
> You received this message because you are subscribed to the Google Groups "
> [email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
>

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].

Reply via email to