modifying zturn_ztio unclear #77
Comments
Two reasons:
Yes, for scoping the dpll timer pins directly
Yes, I pulled the pins for the bga from the schematic they provided. In the hostmot2 PIN file comments the io carrier header pin is called out. I want to make a table of the choices, I just haven't had time.
I see no reason why you couldn't have an odd number of header pins, but the PIN files are all based on 144 pins in the vhdl descriptor. That's the only hard limit I've seen. As for the driver, the hm2_soc_ol patch I submitted doesn't regulate the number of pins at the hal layer provided your firmware protobuf message has the correct amount. See machinekit/machinekit@5bda85e#diff-808b7a7bb9570ae3fe0ecd40f35dfcb9R427 |
Oops, missed this one. You need to do a few things if you want to expand the number of pins exposed. If you just want to reconfigure within the 34 pin limit, you just update the PIN file and recompile without needing to touch the tools directly. Until someone is comfortable with the generated config files, it's probably easiest to generate the necessary bits using the gui tools. Run the make_bitfile script on the project you want to work with, then open Vivado. Browse to the project_name_created directory and open the created project file. On the left side, click open block design and you will see the high level components it takes to build a zynq firmware. To increase the ztio project to 60 pins:
Save, and the project should compile. All of the changes above, with the exception of the PINS and physical BGA constraints file, are temporary. To make them permanent, you would export the block diagram and diff it against the tcl file in the scripts folder that generates the block diagram. The generated scripts are specific to your machine, whereas the example scripts use relative directories. It's pretty straightforward to see the changes you need to accept versus the ones to leave out. I use a graphical diff for this (Meld). After updating the script files, you can run make_bitfile and it will compile and generate the needed bitfiles for linux programming. I will document all of this, and I want to make a screencast of what I described above to make a custom project, and to extend an existing project without wrecking an already existing config. I just need work to slow down a bit before I can make those, but it's on the way I promise. |
|
I kindof got this baked to the extent a bitfile is generated from this config I think I got entangled in misinterpretation of how IDROM PortWidth, IOPorts, IOWidth, the llio values num_ioport_connectors + pins_per_connector, and the fwid struct interact it went like this:
that bitfile doesnt load though: where I think I went wrong is
I'm happy to teach fwid.c or hostmot2 in general to be more sensible with different-width connectors, but frankly I'm lost with the parameters :-/ |
|
These parameters refer to the hostmot2 wrapper: `CONFIG.IOPorts The number of IO ports exposed by HM2. hostmot2 assumes all of the ports are even width. `CONFIG.IOWidth The total number of IO pins exposed (usually IOPorts * PortWidth) `CONFIG.PortWidth The width of an individual port And this parameter is a member of the input output bus tristate component: `CONFIG.WIDTH The total width of the IOBits bus, should equal IOWidth |
This says your fwid message has a mismatch with the IDROM. Where is the fwid python file for this config at? |
|
Oh, the mismatch is in the PIN file here https://github.com/mhaberler/mksocfpga/blob/pins64/HW/VivadoProjects/zturn/zturn_ztio64/const/PIN_ZTIO_64.vhd#L80: It should read: |
mhaberler
pushed a commit
to mhaberler/mksocfpga
that referenced
this issue
Aug 30, 2016
|
@thanks, applied fix! loads now (still suppressing error exits) (hopefully last) questions:
|
|
LEDs are independent of the IO pins. So, to change the LED count, you adjust the CONFIG.NumLEDs(?) parameter, and then make that match in the fwid. For your example CONFIG.WIDTH = 64.
I thought the number of IO pins per port was limited to the bus width of the device, but the register map may disagree. For me, I would prefer 2 ports at 32 width because it saves reads/writes from the processor to fpga fabric (which is slow). But, if you're not controlling fast IO, it might not be an issue.
Yes it should. The number of ports in the fwid message should match the number of ports in the PIN file descriptor which is read in at run time, or the driver will fail because it needs to know how many IO ports it should expect for the hal config being loaded. Allocation of the proper address space (e.g., do I need 4 addresses or only 2 to talk to my outputs, etc.), I'm pretty sure is based off of the count of the IOPorts in the module descriptors. That means we could probably eliminate the IO mismatch guard and provided the correct firmware is loaded, it should work just fine. I like the config double check though, it's not much work and only happens at startup. |
|
Oh, btw, when you edit the config file directly, you need to account for the new pin connections. That's why I mentioned it is easier to use the GUI to generate a script you can then diff against the git commited command line script. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
studying the zturn_ztio config:
Assuming I do not use the Camera, LCD, and ADC connectors I would have the following connectors available at the IO cape:
so a total of 60 pins
semi-related:
The text was updated successfully, but these errors were encountered: