SOCkit Hard Processor System - problems getting started (unassigned pins, vhdl lib)

[Altera_Forum]

I've been working on FPGAs now for a year or so - building my own Atari 800XL clone in hardware. This is running on several boards using pure VHDL, except for the PLL. On all other boards I'm using a ZPU as a support CPU to do drive emulation etc.  

 I'm now trying to get this running on the Arrow SOCkit board. So far I have the FPGA side working, using block RAM and no communication with the ARM (programming sof via JTAG). I also have the HPS side working in that it boots/runs linux ok. I'm using Quartus 14.1 under Linux. So for the next step I'd like to get both working together.   Here I'm running into issues. I've tried following Howard Mao's tutorial and am stuck on section III, where it starts to include the HPS. I've followed his example on how to create the QSYS setup with the lightweight HPS->FPGA bridge. So far so good...   Then I hit several problems.   Problem 1:  So I include the .qip file, and attempt to add the component to my vhdl top level. The first problem is that I can not instantiate the component by the usual method:  system 1: entity work.mysystem  port map...  or  system 1: entity mysystem.mysystem  port map...  So I solve this by creating a component/end component block then instantiating with:  system 1: mysystem  It seems there must be a vhdl library that the altera ip components are in, I just can not work out what is it. Which library are the altera ip components in? How can I instantiate it with entity syntax?    Problem 2:  The main showstopper...  The qsys system has a bunch of sdram like signals exported. I gather from the tutorial that I'm meant to simply connect these to my top-level with the same names, then the sdram tcl pin assignment script will magically create assignments for me. This script does indeed create some pin settings, however no pin assignments. So when I build it I get a fitter error about lots of pins not having explicit locations. Are these HPS QSys pins real pins assignements? Or 'internal pins' that connect the FPGA to the HPS? How can I solve this?    Problem 3:  I'm not really clear on what the HPS QSys pins I'm connecting are... I've tried setting up HPS in two ways -  i) as Howard described - i.e. setting up very little - this gives an 8-bit SDRAM type interface.  ii) As described in the SOCkit hardware lab - with detailed Micron SDRAM timings, board timings, HPS components. Now the latter gives me many more pins to assign in my top level. Which again the fitter can't find. However what I do not understand it - the HPS is already running Linux. If I program the FPGA am I actually changing HPS SDRAM settings and wiring? Linux is expected to keep running through this? Or are all the HPS settings except the bridges ignored when programming the FPGA from linux?   Problem 4:  Clock domains... QSys has a clock input. Is this just used for the fpga bridges and I can use what I like? I have a very specific PLL clock to have exact PAL or NTSC frequencies and am wondering if my avalon MM slave can directly use this frequency? Or if I need to match the slave frequency to the HPS?   I'm pulling my hair out trying to figure these out, so any advice will be greatly appreciated. If anyone has a _minimal_ vhdl QSys example with just a slave e.g. using LEDs etc I'd be very interested to see it. I could build my project on top of a Hello World like that I guess, but for now I've not had any luck getting examples running.

[Altera_Forum]

I'm not really following problem# 1 so here is some info that might connect the dots. Qsys generates RTL to a subdirectory named after whatever you called the system. In that RTL that was generated should be a verilog file that represents the Qsys system and all the interfaces exported out of the system so you would just instantiate that module Qsys top level module in your VHDL RTL. Quartus will know where all those Qsys generated files are because you included the .qip file which references all that stuff. 

 Problem# 2. You'll need to run a .tcl script that was generated by the SDRAM portion of the HPS. You have to do the same thing when instantiating the SDRAM controller in non-SoC devices too so this is documented in the memory controller documentation. Off the top of my head it'll be called something like <HPS/SDRAM instance name>pin_assignments.tcl and is generated in that subdirectory that Qsys generated the RTL into.  Problem# 3 The HPS pins are fixed so you don't need to assign them like you typically do with FPGA I/O but they'll still need to be connected to ports in the top level. When the HPS boots information about the HPS pins are used by the preloader to configure them. The FPGA and it's I/O are configured when the FPGA side of the device is configured either by an external programmer or by the HPS under software control. Interfaces such as the bridges would be connected to other IP in the Qsys system and not connected to ports in the top level.  Problem# 4 By default when you create a new system Qsys assumes you'll be needing a clock source from outside the Qsys system which is almost always the case. This isn't anything to do with the SoC that's just the behavior of the tool. You can use that clock input or use a clock generated from the HPS which is why you almost always need an external clock source since the clock has to come from somewhere (and if you instantiate a Qsys PLL it still needs an input from outside the system). I typically don't use the HPS clocks so that I can work on the FPGA side of the design without having to worry about the HPS being booted to the point where that clock is functional. You need a clock to be connected to all IP in Qsys because the Avalon and AXI connections need to be clocked by something. The synchronous interfaces like the bridges and the FPGA-to-SDRAM ports need to be connected to a clock in the Qsys system since the HPS PLLs only clock the logic on the hard silicon side so the FPGA facing side needs a clock too.  If you haven't already done so I *highly* recommend taking a look at the design that ships with that kit because it'll give you a better idea how the HPS gets integrated into the FPGA design. Also if you are new to Qsys it's probably worth becoming familiar with a tutorial or online course for it so that you'll know what all it's doing behind the scenes for you and why it's being used.

[Altera_Forum]

Thanks BadOmen. Appreciated. 

 Quite a lot of my confusion before was that I was not understanding that the HPS configuration is separate form the FPGA configuration. So even though its designed as one unit in the FPGA there is another tool to then extract the HPS settings and create a pre-loader. Though I've still not tried this...  Anyway the tutorials were all showing this by not, or partially, setting up the HPS side. In fact it seems the HPS side just needs instantiating in QSYS in order to allow the bridges to be used. It does not need configuring at all, except those parts that are related to the FPGA side (which bridges are active etc).  I was further confused by the HPS crashing whenever I wrote to the FPGA via dd to /dev/fpga0. This turned out to be caused by a kernel module loaded by default in the GSRD. I removed gsrd_init.sh from /etc/init.d (Which runs mod probe gpio-altera) and then it all behaves much better. I can flash the FPGA side without the kernel crashing! Also the bridges pretty much 'just work', once I get my avalon mm signals right. It turns out the altera fabric deals with all the clock domain crossing issues and I can just clock the FPGA side of the avalon MM interface as I wish. Which makes things much easier than I was worrying.  My remaining challenges are to get USB working and DDR3 SDRAM FPGA side working. I bought a USB OTG->USB adaptor but the kernel does not recognise any devices. I see no usb host modules in /lib/modules so I guess I need to build my own kernel in order to get that going. Did anyone manage to get USB OSG host working with the GSRD?  As for DDR3 SDRAM, it looks really complex! I'm familiar with 'old' SDRAM having written my own basic controllers, calculated PLL phase offsets etc. The DDR3 looks a bit 'next level' though that is simplified by the Altera IP. So I tried adding the UNIPHY in QSys but the connections make no sense to me. I was hoping there was a way to present the SDRAM as something like an avalon MM slave that I can run my own clock line to. Anyway sure I'll figure it out... I hope!    --- Quote Start ---  I'm not really following problem# 1 so here is some info that might connect the dots. Qsys generates RTL to a subdirectory named after whatever you called the system. In that RTL that was generated should be a verilog file that represents the Qsys system and all the interfaces exported out of the system so you would just instantiate that module Qsys top level module in your VHDL RTL. Quartus will know where all those Qsys generated files are because you included the .qip file which references all that stuff.   --- Quote End ---   I'm including the .qip file. It just seems I need to add a component section to my architecture in order to use it. This seemed odd to me. However in qsys there is a menu setting to generate a 'vhdl usage example' from which I can cut and paste the component.   I found this video quite helpful, though its for a different board: https://www.youtube.com/watch?v=2wuket4-q7q    --- Quote Start ---   Problem# 2. You'll need to run a .tcl script that was generated by the SDRAM portion of the HPS. You have to do the same thing when instantiating the SDRAM controller in non-SoC devices too so this is documented in the memory controller documentation. Off the top of my head it'll be called something like <HPS/SDRAM instance name>pin_assignments.tcl and is generated in that subdirectory that Qsys generated the RTL into. Problem# 3 The HPS pins are fixed so you don't need to assign them like you typically do with FPGA I/O but they'll still need to be connected to ports in the top level. When the HPS boots information about the HPS pins are used by the preloader to configure them. The FPGA and it's I/O are configured when the FPGA side of the device is configured either by an external programmer or by the HPS under software control. Interfaces such as the bridges would be connected to other IP in the Qsys system and not connected to ports in the top level.  --- Quote End ---    Thanks. I see now these are external HPS pins. which programming the FPGA does not configure. If I just run the .tcl script (I was doing that) then the fitter complains about no pin locations. So I assigned explicit locations to the HPS pins as shown in the video above. I think these are not used except by the preloader, I'm not sure if there is any harm in not connecting them if not using that.  Thanks for all the help and advice. Still lots to learn about this board but its getting clearer!  My core is now running pretty well. If I can get USB and SDRAM going I'll be happy:-)

[Altera_Forum]

I've been through the same Mao III tutorial and have the same questions as# 2 and# 3 above. One thing I still don't understand is: if you look at the pdf schematic (watermarked by Terasic) that comes with the SoCKit SystemCD, the pins to the Cyclone V generally don't match the HPS pins assigned by the fitter after full compilation. For example, after compilation, the fitter assigns hps_memory_mem_a[14] to PIN_AJ2 on the Cyclone; but when I look at the Terasic schematic sheet 3 of 30, PIN_AJ2 seems to be connected to the VGA port.  

 I suppose it's something simple I'm missing, but for now i am perplexed.  I have SoCKiT rev c board and documentation. Of course, it also doesn't give me a warm and fuzzy that Terasic has the part# wrong on the schematic.

[Altera_Forum]

Were you using tutorial files for a different board and then looking at the SoCKit schematic? I ask because I've been there done that ...

[Altera_Forum]

Hello foft et.al., 

 Perhaps you (or anyone else) can help me, because I still do not understand the answer to your Problem 2 above.   I too have SoCKIt, and am now on Mao VII tutorial (MD5 cracker). I just finished the Qsys design, which has an hps (with a conduit to on-chip memory) and three Avalon slaves which have avs_* signals connected to the AXI Master as well as md5_* signals exported as conduits to the verilog modules (which of course get implemented in the fpga portion).   I did not do any manual pin assignments. Instead, the pin assignments were done by two processes, 1) the qsys generated TCL script for the memory pins, and 2) the fitter during compilation for all other pins/signals.  My problem is this: the fitter produces some pin assignment that make no sense to me. For example, one of the conduit signals is a READDATA signal, and the fitter assigns it to pin AA16, which is a clock pin! How can that be? There are other examples which also do not make sense to me.  Note AA16 is a clock pin both on the SOCKIT board schematic and on the Quartus Pin Planner instantiation of the Cyclone V 5CSXFC6D6F31C8 (which is the device on SOCKIT). I can understand the fitter does not know about SOCKIT, but it does (or should) know about the 5CSXFC6D6F31C8, AND SHOULD NOT ASSIGN A READDATA CONDUIT TO A CLOCK PIN.  Can anyone please shed some light on this? There must be something basic I'm not understanding. THANKS!  PS. I also don't understand why the READDATA conduit signal has to be assigned to a pin at all. It just comes from the fpga portion of the chip.