Gidel FPGA cards - ProcSpark II and ProcStar IV

Blogs & guides and tales of woo by forum members.
foft
Posts: 344
Joined: 28 Mar 2022 12:20

Gidel FPGA cards - ProcSpark II and ProcStar IV

Post by foft »

I bought a ProcSparkII for the CTPCI project, so I can snoop the bus - and maybe figure out the longstanding DMA bug. I then ended up getting interested in it and bought another PCIe one! :lol:

Also wondering if I can run some fpga system cores then DMA them to the Radeon video ram and the DSP audio buffer...

Anyway I thought I'd write up some of the investigations on a blog here because, I think, they are kind of interesting. To me at least.

So anyway starting with the ProcSparkII. This is an FPGA PCI board.


Image


I now know that it was supported by Gidel by their ProcWizard software and ip. Essentially it had two FPGA chips, one to decode PCI and provide a simpler local bus. The other has a user design on.

Anyway I started by looking over the board to see what was on it:
Board boots with vendor id 165c, device id 5435 -> gidel proc spark. So Cyclone 1 contents seems original.
epcs4 with AS interface -> read contents to POF
U15: Quickswitch 24 way
U3: EPCS4N
EPC/J1: Active serial for EPCS4N
U7: 50MHz clock
U5: 525-01/02 clock chip
U2: Board controller FPGA: Cyclone 1 EP1C4F324C7N: 400LAB/4000LE, ~10KB RAM
U1: Cyclone II EP2C35F672C7N: 2076LAB/33216LE, 60KB RAM
U13: PI49FCT32803 - 3.3V low skew clock buffer
U14: "
U12: MT46V16M16 -32MB DDR
U11: "
J2: EP1C4 JTAG
J3: EP2C35 JTAG
foft
Posts: 344
Joined: 28 Mar 2022 12:20

Re: Gidel FPGA cards - ProcSpark II and ProcStar IV

Post by foft »

So, without a pinout files it kind of tricky.

I was hoping to work out a pinout of the Cyclone I and Cyclone II by using the J-Link boundary scan and/or using signal tap II software (onboard logic analyser) and a design that toggles pins.

Connecting up the JTAG (J3) I saw the Cyclone II. I soldered on a header onto a JTAG like footprint (J2) and from there I can see the Cyclone I.

I managed to set and watch pins using the J-Link boundary scan device, using pyjtagbs. Its really cool, this is going to be very useful for debugging future projects. Essentially after building it you can load a BDSL file to get the device details. Then you can put it in 'passive mode' where it all runs as usual but you can read pin values. Or you can put it in active mode. That turns off the design and allows pins to be toggled low/high/Z etc.

So, I tried:
i) Load a design with signal tap to Cyclone II.
ii) Toggle pins from Cyclone I.

Immediately two problems:
a) The design on the Cyclone II seemed to vanish, something was clearing it!
b) When I set the Cyclone I to active mode the Cyclone II vanished from the JTAG!
foft
Posts: 344
Joined: 28 Mar 2022 12:20

Re: Gidel FPGA cards - ProcSpark II and ProcStar IV

Post by foft »

So I figured the JTAG is probably going via Cyclone I pins to Cyclone II. Well I actually tried to use the Cyclone II JTAG and saw pins toggling on the Cyclone I.

Some notes I took from this stage below:

If I use the jtag on cyclone 2 these pins change on cyclone 1
4 IOM8
2 ION8
2 IOR13
2 IOR14
{'name': 'IOM8', 'location': '', 'type': ['input', 'output', 'oe'], 'id': 184}
{'name': 'ION8', 'location': '', 'type': ['input', 'output', 'oe'], 'id': 201}
{'name': 'IOR13', 'location': '', 'type': ['input', 'output', 'oe'], 'id': 238}
{'name': 'IOR14', 'location': '', 'type': ['input', 'output', 'oe'], 'id': 239}

When I'm doing nothing these pins change on cyclone 1
21 IOB5
24 IOC2
19 IOU5

If I clear all cyclone 1 function in active mode, then the jtag stops working. However if I try to use jtag I then see:
IOR14

More experiments by grounding a pin and seeing what changes
In active mode... when jtag broken:
IOR14: TCK
IOP7: TDI
(ION10/IOR13: TDO)
IOR13: TDO (2nd try)
(ION11/IOM11: TMS)
IOM11: TMS (2nd try...)

In passive mode... when jtag working:
IOR14/ION8/IOM8:TCK
IOP7/IOU3: TDI
IOR13: TDO
IOM11/IOT14: TMS
foft
Posts: 344
Joined: 28 Mar 2022 12:20

Re: Gidel FPGA cards - ProcSpark II and ProcStar IV

Post by foft »

From that I made a simple design for the Cyclone I board controller (bridge from PCI pins to Cyclone II user design, clock routing and JTAG routing)

With this I'm able to use the Cyclone II JTAG again ... and the design stays!

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;

LIBRARY work;

ENTITY board_controller IS
        PORT
        (
                CLK0     : IN STD_LOGIC;
                CLK2     : IN STD_LOGIC;

                CYCLONE2_TCK_IN : IN STD_LOGIC;
                CYCLONE2_TDI_IN : IN STD_LOGIC;
                CYCLONE2_TDO_IN : IN STD_LOGIC;
                CYCLONE2_TMS_IN : IN STD_LOGIC;
                CYCLONE2_TCK_OUT1 : OUT STD_LOGIC;
                CYCLONE2_TCK_OUT2 : OUT STD_LOGIC;
                CYCLONE2_TMS_OUT : OUT STD_LOGIC;
                CYCLONE2_TDI_OUT : OUT STD_LOGIC;
                CYCLONE2_TDO_OUT : OUT STD_LOGIC
        );
END board_controller;

With these assignments of note:
set_location_assignment PIN_D16 -to CYCLONE2_TDO_IN
set_location_assignment PIN_M8 -to CYCLONE2_TCK_OUT1
set_location_assignment PIN_M11 -to CYCLONE2_TMS_IN
set_location_assignment PIN_N8 -to CYCLONE2_TCK_OUT2
set_location_assignment PIN_P7 -to CYCLONE2_TDI_IN
set_location_assignment PIN_R13 -to CYCLONE2_TDO_OUT
set_location_assignment PIN_R14 -to CYCLONE2_TCK_IN
set_location_assignment PIN_T14 -to CYCLONE2_TMS_OUT
set_location_assignment PIN_U3 -to CYCLONE2_TDI_OUT
ARCHITECTURE vhdl OF board_controller IS
BEGIN
        CYCLONE2_TCK_OUT1 <= CYCLONE2_TCK_IN;
        CYCLONE2_TCK_OUT2 <= CYCLONE2_TCK_IN;
        CYCLONE2_TDI_OUT <= CYCLONE2_TDI_IN;
        CYCLONE2_TMS_OUT <= CYCLONE2_TMS_IN;
        CYCLONE2_TDO_OUT <= CYCLONE2_TDO_IN;
END vhdl;

Return to “MEMBER BLOGS”

Who is online

Users browsing this forum: apple [bot], ClaudeBot, Google [Bot], petal [bot], Qwantbot and 15 guests