Skip to content

Latest commit

 

History

History
113 lines (89 loc) · 11.8 KB

0028-2020-06-09.md

File metadata and controls

113 lines (89 loc) · 11.8 KB
Raw

9 Jun 2020

  • I want to see if I can get pace_old working, ideally in 64-bit mode, but 32-bit mode if necessary.

  • NOTE: "PACE" (see also this) is Pinout and Area Constraints Editor.

  • Downloading ISE 14.7 VM on a Mac. Can I manually install the OVA in VirtualBox 6.1.6 on macOS 10.15.5?

  • Doco here on getting ISE (Windows 7 version) to work on different platforms, including Windows 10. Note that this version probably won't support CPLDs, but maybe we can hack that in later from the 14.7 Linux VM. This is where things might start getting interesting too.

  • Maybe this will likewise be handy?

  • In future, for Spartan 3E, etc, this might be handy.

  • Need to investigate Timing Analysis stuff in UCF, to get rid of warnings and hopefully help registers.

  • This guy had some trouble. Maybe his findings will help? That's for Ubuntu, but might provide a guide for Red Hat (14.7 VM default) too.

  • A partial list here of Xilinx ISE tools.

  • Will the XC9500XL BSDL files help with working out manual UCF pin planning for the XC9572XL-7-VQ64? Interestingly:

    • Our LEDs are on FB1-2 (pin 8) and FB2-17 (pin 7).
    • xc9572xl_vq64.bsd sort of implies that these respectively would be known internally as PB00_01 and PB01_16. It appears there are no FB*-1 pins named on the package, in the datasheet. The datasheet naming of the pins doesn't match the BSDL. The TQ100 package does range from FB1-1 up to FB1-18, though.
    • The BSDL also does imply that PB00_01 is P8 and PB01_16 is P7.

  • So, I'm not sure why my code targeting the XC9572XL-7-VQ64 seemed to leave the LEDs in a state where the LEDs were dim. They were probably dim due to WPUs (weak pull-ups, aka KPR or "Keeper" pull-ups that apply by default to unused pins), but shouldn't they have had some value assigned from reset? Need to try some direct assigns instead, and test the theory on both the VQ44 and VQ64.

  • Interesting info re BSDL here.

  • Learn how to do simulation and timing analysis to make sure I understand Verilog correctly.

  • I wonder if the problem is that iMPACT (or the synthesis step) didn't use my UCF. Does the report show what pins it used? I've noticed that test02.gyd (a "guide file") contains this:

    9572XL64 XC9572XL-7-VQ64
SW1 S:PIN57
SW2 S:PIN15
D2 S:PIN60
D3 S:PIN22

    On a VQ64, those pins would be:

    • SW1: P57 = FB4-17
    • SW2: P15 = FB1-9
    • D2: P60 = FB2-2
    • D3: P22 = FB3-2

    Note that this is all very hard to read, but if look at test02.mfd, we see these mystery numbers 87 (for D2) and 29 (for D3). These appear to match pin 60 and pin 22 in the .jed file, so maybe that is what got programmed for some reason...?

    Compare this with test02.pnx and we get the same numbers again. Maybe I forgot to synth again after creating my .ucf??

    Note that test02.rpt shows that SW2 is mapped onto global clock net GCK1 (no doubt for clocking my latch logic). I/O/GCK1 is pin 15, which shows up in test02.pnx too. Is that going to a problem, or does it wire that up internally itself, without changing my outside pin assignment?

    There was also this warning and maybe that implies that it didn't use my correct test02.ise project but rather built its own, hence the arbitrary pin assignments?

    OK this does look wrong...?

    See also: this.

  • I need some sort of breakout that shows the state of all IO pins as LEDs. SMT assembly from JLC? PTH LED bars that I already have?

  • In next version of breakout board, do better refs/naming/placement of LEDs and buttons. Maybe space for more LEDs, too. They don't have to be populated, remember.

  • Check out: https://www.xilinx.com/support/answers/3122.html

  • There are lots of little examples, now, in test03. I then made a project for each one, synthesized them, created iMPACT projects (.ipf files), and produced output/test03*.xsvf files. The final state with all of those can be found here.

NOTE: When wiring up the JTAG header to the BP, use these connections, i.e.:

Bus Pirate Dir JTAG
CS → TMS
MOSI → TDI
MISO ← TDO
CLK → TCK
GND ⏚ GND
3V3 ↑ VCC 3V3 (or VTG)

Success!

All of my test03 experiments worked on my XC9572XL-7-VQ64 board. They demonstrate assigns with wires, generic always blocks, and actual register latching with always @(negedge ...).

By doing md5sum t03?/output/test03?.xsvf | sort I was able to verify that some designs synthesized to exactly the same configuration:

  • A is the same as C (hard setting LEDs: wire; vs always)
  • F is the same as G (LEDs following buttons: separate always blocks vs. combined always block)

I soldered a 50MHz XO (Crystal Oscillator) in order to do some clocked/sequential tests. It feeds GCK3 (FB1-14).

I got test04a working which shows a counter in action.

I was having trouble with test04b. Initially I made a mistake where I forgot about the inverted button logic (i.e. pressed is low). The design was otherwise working. I flipped the logic of each button, but it didn't appear to change the behaviour after I built a new XSVF and programmed it to the board. In fact, none of my attempts to fix the problem seemed to work. I started doing MD5 checksums of each .xsvf file and I found they were always the same. In the end, though, I think it was more of a process issue than a code issue:

  1. The ISE "Play" button means "Implement Top Module".
  2. This seems to go through the first 4 "Implement Design" processes, which produces a .jed file.
  3. Processes don't seem to run again unless ISE determines they need to be run because something gets updated.
  4. I think because of something to do with the VirtualBox host share setup, the .jed file might've been getting a timestamp set in the future.
  5. Whatever the case, ISE was not successfully writing an updated .jed file.
  6. Hence, no matter what I did to the code or whether I tried to force it to synthesize it again in full or not, the .jed file was remaining outdated, and this was being fed into iMPACT to produce an also-outdated .xsvf file.
  7. I found I could usually get arond this by deleting the .jed file and then synthesizing again, but I also got this situation recently: 
    WARNING:ProjectMgmt - File /home/ise/shared_projects/sandpit/fpga/XC9572XL/test04/t04b/working/test04b.jed is missing.
    In that case, I was able to right-click on "Generate Programming File" and select "Run", which made the .jed file.
  8. Between builds, I would check the md5sum output of both the .jed and .xsvf files to ensure they had changed.

So, the test04b code now works.

NOTE: When using iMPACT to record the programming of the core, the output XSVF will be different before and after using the Output => XSVF File => Stop option. It could be that using this "Stop" will do the necessary cleanup/reset steps that cause the target device to restart, and omitting this step might be why sometimes I've seen it go to a hung state after programming instead.

NOTE: I found in some situations that when launching iMPACT, and it auto-opens the prior project, the "Assign configuration file" menu option is missing, and hitting its usual CTRL+G combo once does nothing, and the 2nd time causes iMPACT to crash.

NOTE: For future reference, this is the command I'm using to program test04b to the CPLD:

pushd C:\Users\admin\Documents\shared_projects\sandpit\fpga\BPv3.XSVFplayer.v1.1
BPXSVFplayerV01a.exe -p COM13 -x -f "..\XC9572XL\test04\t04b\output\test04b.xsvf"

What next?

  • Make a start on the fpga4fun.com tutorials.
  • Start planning improvements to the CPLD board. Ideas include:
    • Most of FB1 is mislabeled in the silkscreen! Fix it.
    • Design XO placement better, and maybe use an RS232-compatible frequency.
    • Protection diode.
    • Some dedicated pins with built-in 1kΩ series resistors to avoid overcurrent; i.e. would limit to 3.3mA on a dead short.
  • Try fixing pace_old, because it probably has lots of handy features about voltage levels, etc, for which I don't otherwise know the UCF config (but I suppose I could learn by carefully studying the Constraints Guide). Make a snapshot of the VM first.
  • Make a better cable to connect the BP directly to the JTAG header.
  • Learn how to do simulations in ISE.
  • Make a core that tests each pin in turn, in the order seen on the edge connectors. See if it's possible to make an SVF that slowly does the same using pure JTAG.
  • See if it's possible to link the ISE VM directly to the Bus Blaster for programming the XC9572XL. Apparently it is possible (though slow) using a special driver. For more info, see: http://dangerousprototypes.com/forum/index.php?topic=3588.0