HDG2002B AWG Firmware Reverse Engineering

[tinhead]

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

Did you try the one posted by Tinhead?: https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

actually my bsdl is nt working as well, one can not use it with e.g. universal scan (getting tons of syntax errors) and with topjtag is doing eact the same, meaning nothing, update on pins only during powerup but then no informations anymore.

So is that the BSDL file or something strange about the JTAG interface on the chip?

well, hard to say. The bsdl provided by Cyber7 seems to be good (from TopJTAG point of view), and with little modification i was able to load it into UniversalScan (attached, i had to remove names of registers that does not have ports defined, like CAM interface which does not exist on S3C2416 but one the bigger brother S3C2450). However, still no pins updates in sample mode nor any action/reaction in extest mode. When i change boot mode (i'm testing on s3c2416 dev board) to illegal state and reset it, the SoC is starting and data shown on jtag (i can then even play with extest mode). So looks like something is blocking jtag. I thought it might be nand data, but without nand (i do have nand in socket on my dev board) same result - no pins scan etc. I can't test jtag boot mode due hardwired OM0 on my dev board), but that would still not do the job for you guys (as you can't "patch" pcb anyway).

I do have genuine JtagKey and Key2, as well other adapters, so not a jtag<->sw problem.

So whatever it is, i'm not getting jtag scan working :\ It might be still the bsdl, the quality of Samsung provided bsdl is really crap (at least s3c2450 and s3c2416 are not properly working).

[Cyber7]

@tinhead: How did you get the mcu into an illegal state on your devkit?

I don't think it's the jtag or the bsdl. I've been successful in dumping the nand via openocd, so I thought to check into the low-level boundary scan routines since the jtag appears to be working correctly in this instance. I borrowed some tcl routines (manual_bs.tcl) initially made for an STM32 target and altered the instruction opcodes to conform with the s3C24xx mcu's. While I was able to get the IDCODE, any SAMPLE attempt returned either all FF or 00 depending on the processor state. I attached my target board openocd cfg.

Manual attempts also failed with all 0's :

scan_chain

   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 S3C2416.cpu            Y     0x07926f0f 0x07926f0f     4 0x01  0x0f

targets

    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* S3C2416.cpu        arm926ejs  little S3C2416.cpu        running
 
init
halt
poll off
sleep 4000
irscan S3C2416.cpu 14
drscan S3C2416.cpu 32 0

07926F0F     <---matches mcu IDcode
 
irscan S3C2416.cpu 3          <-- sample opcode
drscan S3C2416.cpu 685 0   <-- scan all 685 bits

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xa0000013 pc: 0xc0267770
MMU: enabled, D-Cache: enabled, I-Cache: enabled

drscan S3C2416.cpu 685 0

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[tinhead]

@tinhead: How did you get the mcu into an illegal state on your devkit?

i did setup project (topjtag or universalscan - openocd is not possible to open into that state),  with boot from iROM with NAND attached. Then changed to boot from OneNAND (which does not exists) and enabled eFuse. After reset, with extest enabled, i got access. The only probelm is, due floating input pins it's impossible to get "in" valus and "out" does only works when i/o got randomly switched to out (but the out value is the one i set with extest).
So that not the solution we need.

I don't think it's the jtag or the bsdl. I've been successful in dumping the nand via openocd, so I thought to check into the low-level boundary scan routines since the jtag appears to be working correctly in this instance.

i do not have any issues to access via H-JTAG USB. Sure, DEVICE_ID and BYPASS are working, however what BOUNDARY is doing is unclear for me. There are two possible "jtag modes" for s3c2416, one with OM0:OM4 set to 10001 (which i can't set on my dev board due hardwired pins under the bga, this is boot from jtag and jtag enabled) and OM0:OM4 set to x0010 (which is jtag enabled while irom boot set). But even if i set that mode (and regarding to SMDK2416 docs that should be ok) still no boundary scan

Manual attempts also failed with all 0's :

tried as well, with/without the iROM+JTAG boot option as described above, but no result :\

Unfortunately Samsung never responded to my questions about S3C2416 boundary scan (~ 2yrs ago).

[alex.forencich]

How important is the boundary scan on the device?  It seems like it will not be easy/possible to get working.  I had a similar issue on some Virtex 4 FPGAs - I could not get the pins to toggle under the control of the boundary scan, so I could not do pin mapping between multiple devices automatically.  It did work for external sources, just not another Virtex 4 - and there were 11 FPGAs on one board I was trying to get sorted out. 

I think most of the pins aren't really all that important to look at - the memory and display connections are already made at fixed locations, etc. Perhaps what we should do is just write some test code to toggle pins and then check with the scope to see what pin is toggling.  A few educated guesses go a long way - we're mainly interested in SPI and I2C, no?  Those pin locations are indicated in the datasheet.  I'm not sure if we're going to be able to do much better than that without cracking our heads against the wall for a long time. 

[Cyber7]

Well, it would have been nice to have full control of both the fpga & soc. The original SMDK seems to have allowed full access to the OM selector via dip switch. Would have made life easier.

The SDRAM arrangement does indeed look correct. I've also found a schematic with the exact same devices which confirms the pinouts on Banks 1/3.

Since TopJTAG does not work with the Xilinx platform USB cable, I had to rig my Altera USB blaster to work with the onboard xilinx jtag pinout. It actually does work!

I unremarked the SDRAM's from the contraint file and imported it to name the pins. That way I could eliminate them as knowns. Then I set watches on all remaining un-named pins. I wish pins could be masked out so they can easily be ignored on the led pin display.

I reset the FPGA, keeping all input pins in hi-z, then ran /dso/app/test_cmd which sends no command without an SCPI parameter, however it always initializes the front end relays. I noted transitions on FPGA pins P8 ( 70 ), R13 ( 14 ), R15 ( 8 ). P8 may be sdi or sck from the SOC. The sampling rate from the Altera BB doesn't allow for accurate waveforms. Time to break out the scope and check the shunted isolation bridge for contemporaneous transitions.

[alex.forencich]

What schematic did you pull those from?  I have been trying to confirm the RZQ and ZIO pins.  The RZQ pin should be connected to GND through a resistor and the ZIO pin should be no connect.  They can be any unused pin in the same bank.  I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.  The schematic you have shows C2 and L6.  Does that schematic show another DDR2 memory connection?  If so, which RZQ and ZIO pins are being used? 

Also, which board rev do you have?  I have 1004, but it is possible there are FPGA pinout differences between the boards. 

R13 and R15 are DIN and CCLK, so whatever is connected to R13 would have to be MOSI and R15 would have to be SCK.  However, I am not sure if those pins can be assigned in the UCF file. On my board, N9 and R13 are connected and P12 and R15 are also connected so N9 and P12 are likely to be the actual MOSI and SCK pins.  P8 I was not sure about, it could be chip select or reset.  In the other direction, M10 seems to be the most likely candidate for MISO as the other three pins through that isolator are DONE, INIT, and PROGRAM_B. 

[Cyber7]

They're schems from an Opal Kelly dev board http://www.opalkelly.com/products/xem6006/ They do not show the bank 1 connections.

I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.

The schem agrees with bank 3 C2/L6, I also have another schem from a Siga SPartan 6 dev kit with only 1 SDRAM on bank 3 that also agrees with the same pinout.

There's continuous traffic on C2/C18, even if the SOC is halted, unless I reboot the SOC and prevent the fpga bitstream from being loaded.

My board is rev 1004.

I have seen R13 and R15 on another UCF declared as:

NET "FPGA_D0_DIN_MISO_MISO1"  LOC = "R13";
NET "FPGA_CCLK" LOC = "R15";

Will continue inspection tomorrow. P8 looks too chatty when i issue a command for a cs/rst; looks more like a clk/mosi.

[alex.forencich]

They're schems from an Opal Kelly dev board http://www.opalkelly.com/products/xem6006/ They do not show the bank 1 connections.

I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.

The schem agrees with bank 3 C2/L6, I also have another schem from a Siga SPartan 6 dev kit with only 1 SDRAM on bank 3 that also agrees with the same pinout.

There's continuous traffic on C2/C18, even if the SOC is halted, unless I reboot the SOC and prevent the fpga bitstream from being loaded.

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct. 

My board is rev 1004.

I have seen R13 and R15 on another UCF declared as:

NET "FPGA_D0_DIN_MISO_MISO1"  LOC = "R13";
NET "FPGA_CCLK" LOC = "R15";

Will continue inspection tomorrow. P8 looks too chatty when i issue a command for a cs/rst; looks more like a clk/mosi.

It may be possible to access those pins from the fabric.  It is not possible on all of the FPGAs - I tried to use CCLK as an input on a Virtex 4, and it gave me an error. 

R15 is called IO_L1P_CCLK_2 and and R13 is called IO_L3P_D0_DIN_MISO_MISO1_2, so it seems like those can be used as general I/O in bank 2.  On the Virtex 4 it is just called CCLK_0 and the bank is undefined.  Accessing these pins from user logic may be possible. 

Also, can you check for activity on P12, N9, and M10?  These are listed in the UCF file as cntrl_sck, cntrl_mosi, and cntrl_miso.  Not sure if you are ignoring activity on these at the moment or not. 
On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6. 

[Cyber7]

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct.

I believe you are right. See page 33 of the Spartan 6 Memory Controller guide (link below). The guide should prove useful in setting up the SDRAM parameters for synthesizing the controllers with the Xilinx MIG. I need to look into this and write up some simple pattern/walk tests.

http://www.xilinx.com/support/documentation/user_guides/ug388.pdf

Here's a nice guide: http://www.xilinx.com/support/documentation/boards_and_kits/xtp039.pdf

Also, can you check for activity on P12, N9, and M10?

I recall seeing some duplicate traffic to R13/R15. I wasn't looking at documented pins, so I'll check again. Wish I could get more than 3-400samps/sec out of this jtag.

[alex.forencich]

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct.

I believe you are right. See page 33 of the Spartan 6 Memory Controller guide (link below). The guide should prove useful in setting up the SDRAM parameters for synthesizing the controllers with the Xilinx MIG. I need to look into this and write up some simple pattern/walk tests.

What do you think I have been reading forwards and backwards for the past week?  Right now I am working on a MyHDL model of a multiport memory with Spartan 6 MCB-style interfaces so the core logic can be tested without having to simulate the entire memory controller.  The MCB 'classic' interface is a bit lighter-weight than a full AXI interface, which is important for this application due to the limited size of the FPGA.  Especially because the classic interface requires no additional logic - it is a direct connection to the hard IP memory controller - while the AXI interfaces are implemented as a wrapper on top of the hard core interfaces, so using AXI interfaces requires a larger overhead in LUTs. 

http://www.xilinx.com/support/documentation/user_guides/ug388.pdf

Here's a nice guide: http://www.xilinx.com/support/documentation/boards_and_kits/xtp039.pdf

Dang, that's for an old version of ISE...I have 14.7 system edition installed...

I have a core generated, I'm just in the process of figuring out how I'm going to verify that it works correctly.  I may just have to put in a chip scope instance to look at the error signals. 

Also, can you check for activity on P12, N9, and M10?

I recall seeing some duplicate traffic to R13/R15. I wasn't looking at documented pins, so I'll check again. Wish I could get more than 3-400samps/sec out of this jtag.

Those pins go through the resistor arrays that bridge over the isolator footprints.  You can easily put a scope probe on those pins and capture the SPI data. 

[idpromnut]

Quick update on the Penguin end of things:

• I have been dicking around with UBoot (the boot loader for the HDG2000), and it looks like either there will be some work to integrate the modifications that were posted by Hantek (in the DSO5000 drop they did) into the most recent version of UBoot. The other option (which I need to try out tonight) is to build their UBoot tree and see if I get useable output. If so, I will probably just leave the boot loader alone for a bit and focus elsewhere.
• The "elsewhere" will be getting the Linux kernel that I have booting now to boot the NAND flash with the existing Hantek Firmware. This will let me do a couple of things:
  
  • have a way of "sanity checking" that a linux build works
  • check that I'm not missing built in drivers that are needed for the HDG2000
• After getting a kernel booting the existing firmware, I will focus on booting from SD; that will let me build and test this whole beast while leaving the stock firmware in-place.
  
• A distant third on this list will be exploring Hantek's firmware upgrade process (har har har) and seeing if I can alter the UBoot options from the linux environment and save them so I can create an "upgrade" firmware package that will allow you to change the target boot to the SD or back to the internal NAND. This will facilitate other people when developing and testing firmware releases.
  

[alex.forencich]

I have one DDR2 controller operational at 625 MHz.  I just modified the example design to run with a 10 MHz input clock, set the pins in the UCF file, and dropped it on the board.  Interestingly, it seems there is some sort of a startup transient error condition - the testbench error output goes high immediately after the calibration sequence completes.  I'm not sure why this is.  Reading out the port 0 status information with chipscope after startup indicates no compare errors.  However, if I reset the design continuously and grab a trace with chipscope, then I do see a short stream of compare errors at the beginning of the trace.  However, after this settles down, the core seems to work perfectly.  I tested both the standard address-as-data mode as well as the hammer and neighbor modes that look for crosstalk.  I have yet to see any errors after startup.  Next step is to try the other controller. 

[alex.forencich]

Trace of one of the data lines between U5 and U8 while running PRBS test data.  Signal integrity looks decent.  I'm not triggering on the absolutely most correct signal for this to be perfect, so there are lots of overlapped traces with different patterns and offsets. 

[alex.forencich]

The other channel (U12) also works correctly.  Same transient startup error, but it is fine after that with hammer, neighbor and PRBS test modes. 

[Cyber7]

That's good news! Can you post your MIG options summary? What percentage of the device's LUT's are utilized per controller?

On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6.

Yes. See attached image.

I ran short on time today, but I've built a makeshift tap for the isolation bus data pins and put my logic analyzer on it. Seems a negative Slave Select initiates an SPI transaction, See attached image for tentative pinout, and snippet from a transaction. The bytewise interpretation may not be correct. I'll see about backtracking miso to the fgpa.

Edit: M10 = MISO confirmed
        Looks to me like P8 = MOSI

[alex.forencich]

I just finished writing a new MCB wrapper script that is a bit more cleaned up and doesn't automatically pull in a PLL.  And I take back what I said before, it seems like it is possible for one PLL to drive two BUFPLL_MCB on opposite sides of the device.  I have one PLL_ADV instance driving two BUFPLL_MCB to drive the MCBs, and it synthesized without any errors.  So I will probably go ahead and stick a PLL in the 250 MHz clock for the DAC and DSP components. 

Here is the current utilization:

Code: [Select]

Device Utilization Summary:

Slice Logic Utilization:
  Number of Slice Registers:                   763 out of  18,224    4%
    Number used as Flip Flops:                 763
    Number used as Latches:                      0
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
  Number of Slice LUTs:                      1,160 out of   9,112   12%
    Number used as logic:                    1,146 out of   9,112   12%
      Number using O6 output only:             826
      Number using O5 output only:              72
      Number using O5 and O6:                  248
      Number used as ROM:                        0
    Number used as Memory:                       1 out of   2,176    1%
      Number used as Dual Port RAM:              0
      Number used as Single Port RAM:            0
      Number used as Shift Register:             1
        Number using O6 output only:             1
        Number using O5 output only:             0
        Number using O5 and O6:                  0
    Number used exclusively as route-thrus:     13
      Number with same-slice register load:      3
      Number with same-slice carry load:        10
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                   440 out of   2,278   19%
  Number of MUXCYs used:                       200 out of   4,556    4%
  Number of LUT Flip Flop pairs used:        1,293
    Number with an unused Flip Flop:           574 out of   1,293   44%
    Number with an unused LUT:                 133 out of   1,293   10%
    Number of fully used LUT-FF pairs:         586 out of   1,293   45%
    Number of slice register sites lost
      to control set restrictions:               0 out of  18,224    0%

  A LUT Flip Flop pair for this architecture represents one LUT paired with
  one Flip Flop within a slice.  A control set is a unique combination of
  clock, reset, set, and enable signals for a registered element.
  The Slice Logic Distribution report is not meaningful if the design is
  over-mapped for a non-slice resource or if Placement fails.

IO Utilization:
  Number of bonded IOBs:                       177 out of     232   76%
    Number of LOCed IOBs:                      177 out of     177  100%
    IOB Flip Flops:                             34
    IOB Master Pads:                             1
    IOB Slave Pads:                              1

Specific Feature Utilization:
  Number of RAMB16BWERs:                         0 out of      32    0%
  Number of RAMB8BWERs:                          0 out of      64    0%
  Number of BUFIO2/BUFIO2_2CLKs:                 0 out of      32    0%
  Number of BUFIO2FB/BUFIO2FB_2CLKs:             0 out of      32    0%
  Number of BUFG/BUFGMUXs:                       6 out of      16   37%
    Number used as BUFGs:                        4
    Number used as BUFGMUX:                      2
  Number of DCM/DCM_CLKGENs:                     2 out of       4   50%
    Number used as DCMs:                         0
    Number used as DCM_CLKGENs:                  2
  Number of ILOGIC2/ISERDES2s:                   0 out of     248    0%
  Number of IODELAY2/IODRP2/IODRP2_MCBs:        48 out of     248   19%
    Number used as IODELAY2s:                    0
    Number used as IODRP2s:                      4
    Number used as IODRP2_MCBs:                 44
  Number of OLOGIC2/OSERDES2s:                 124 out of     248   50%
    Number used as OLOGIC2s:                    34
    Number used as OSERDES2s:                   90
  Number of BSCANs:                              0 out of       4    0%
  Number of BUFHs:                               0 out of     128    0%
  Number of BUFPLLs:                             0 out of       8    0%
  Number of BUFPLL_MCBs:                         2 out of       4   50%
  Number of DSP48A1s:                            0 out of      32    0%
  Number of ICAPs:                               0 out of       1    0%
  Number of MCBs:                                2 out of       2  100%
  Number of PCILOGICSEs:                         0 out of       2    0%
  Number of PLL_ADVs:                            1 out of       2   50%
  Number of PMVs:                                0 out of       1    0%
  Number of STARTUPs:                            0 out of       1    0%
  Number of SUSPEND_SYNCs:                       0 out of       1    0%

TL;DR: we still have about 80% of the FPGA available for the rest of the logic. 

[alex.forencich]

That's good news! Can you post your MIG options summary? What percentage of the device's LUT's are utilized per controller?

MIG project file is in the repo.  I think you can run it with the webpack license.  Just run 'make' in the coregen subdirectory.  The LUT utilization is very low as the MCB is a hard core.  The LUTs it requires directly are only for calibrating the termination impedance. 

On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6.

Yes. See attached image.

I believe the CCLK and DIN pins connect through these components to the SoC so they can be isolated if an external config flash is used for the FPGA.  Initially I thought your board must be different from mine because you did not list any activity on the pins I had guessed were for the SPI port in the design. 

I ran short on time today, but I've built a makeshift tap for the isolation bus data pins and put my logic analyzer on it. Seems a negative Slave Select initiates an SPI transaction, See attached image for tentative pinout, and snippet from a transaction. The bytewise interpretation may not be correct. I'll see about backtracking miso to the fgpa; I'll also look into cntrl_sck, cntrl_mosi, and cntrl_miso.

Edit: M10 = MISO

This is exactly what I had guessed.  From what you have in your image, it should match the UCF file exactly.  Also, I went ahead and added the CS pin to the UCF file as well. 

[Cyber7]

For greater resolution than that available via jtag: Do you think it possible to write a dummy fpga project, with a modified UCF setting all pins to tristate except the pins we wish to probe for input & use Chipscope to record the waveforms?

[alex.forencich]

For greater resolution than that available via jtag: Do you think it possible to write a dummy fpga project, with a modified UCF setting all pins to tristate except the pins we wish to probe for input & use Chipscope to record the waveforms?

Well, there are a few options.  We could use chipscope, but you need a license for that.  Another possibility is to route interesting signals through to the digital output connector on the front and then connect a logic analyzer to that.  Any pin not allocated will end up being tristated, possibly with a weak pull-up. 

However, I think I have probed just about everything there is to probe from the FPGA side.  I know what all the pins are to control the front end components, DACs, DDR2, digital out, ADC, etc.  The specifics of the protocols can be gleaned from the part datasheets.  Besides, what is there to probe once you remove the FPGA configuration?  And we're going to be rewriting the SPI interface anyway, so the specifics of that aren't really all that important, unless you want to be able to control the default FPGA configuration. 

The main mystery I have been stuck on is what the other pins on the analog mux (U27) go to.  One input comes from the modulation input, and the output goes to the TI ADC.  However, the analog mux has 7 other inputs, and I have no clue what they are connected to.  Poking around with a multimeter did not turn up anything interesting.  JTAG won't be of any help with that, though. 

[Cyber7]

Another possibility is to route interesting signals through to the digital output connector on the front

Now there's an awesome idea I didn't consider!

For me, it would be a good exercise, since I've little flight time on FPGAs. I'm also more familiar with the Altera tool chain; I find it easier to work with and faster than Xilinx ISE too.

Good to know that the DDR2 logic for both banks will take less than 25% of the device.

Fortunately, as you say, there's little use to decode the SOC<->FPGA SPI comms. It is a bit of a curiosity given the repetitive chatter when running a 'simple'  /dso/app/test_cmd. It overflows the buffer on my analyzer due to all the sck transitions even with transitional compression.

U27 is a PITA. I've overlaid the top/bot PCB images and at least 4 of the Y inputs end in blind vias. Any idea if the chip selects source from the FPGA? Also, what's with all the inductors on the ADC?

Also, Have you verified the front end serial shift registers that operate the relays?

I just ordered an TQ2416 dev kit from Wayengineer.com, so I can work on the Linux side of things while at the office. Hopefully it will come with schematics.

[alex.forencich]

Another possibility is to route interesting signals through to the digital output connector on the front

Now there's an awesome idea I didn't consider!

For me, it would be a good exercise, since I've little flight time on FPGAs. I'm also more familiar with the Altera tool chain; I find it easier to work with and faster than Xilinx ISE too.

Fortunately, as you say, there's little use to decode the SOC<->FPGA SPI comms. It is a bit of a curiosity given the repetitive chatter when running a 'simple'  /dso/app/test_cmd. It overflows the buffer on my analyzer due to all the sck transitions.

U27 is a PITA. I've overlaid the top/bot PCB images and at least 4 of the Y inputs end in blind vias. Any idea if the chip selects source from the FPGA? Also, what's with all the inductors on the ADC?

Also, Have you verified the front end serial shift registers that operate the relays?

Check the UCF file!  I probed all of those pins already. 

Code: [Select]

# U24/U26 front end relay control
NET "ferc_dat"      LOC = "B3"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L4P_0,                  U24.14
NET "ferc_clk"      LOC = "B2"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2P_0,                  U24.11, U25.11
NET "ferc_lat"      LOC = "A2"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2N_0,                  U24.12, U25.11

# U27 Analog Mux
NET "mux_s<0>"      LOC = "T12" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L19P_2,                 U27.11
NET "mux_s<1>"      LOC = "V13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14N_D12_2,             U27.10
NET "mux_s<2>"      LOC = "U13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14P_D11_2,             U27.9

# U30 ADC
NET "adc_sclk"      LOC = "V16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2N_CMPMOSI_2,          U30.15
NET "adc_sdo"       LOC = "U11" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L23P_2,                 U30.13
NET "adc_sdi"       LOC = "U15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5P_2,                  U30.12
NET "adc_cs"        LOC = "V15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5N_2,                  U30.11
NET "adc_eoc"       LOC = "V14" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L12N_D2_MISO3_2,        U30.10
NET "adc_convst"    LOC = "U16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2P_CMPCLK_2,           U30.9

All of the select pins on U27 are routed to the FPGA via ferrite beads (L46-48).  The ADC connections to the FPGA are also routed via ferrites (L49-54).  The front end control shift registers are also connected via ferrites (L40-42).  I believe they put the ferrites in there to prevent noise from the FPGA coupling into the analog components over the signal lines.  Not a bad idea, I suppose. 

On U27 there seem to be two analog inputs that are connected to caps on the other side of the board.  I have no idea if there is a trace on the inner layer that runs off somewhere for those inputs.  I'm hoping that there is a way to route the arb outputs back around to the ADC for self calibration or self test purposes.  It's possible they're connected to one of the front end relays, perhaps the unknown ones X4 and X5.  It's possible that's how Hantek implemented some of the modulation - send it out the door and back in again to save on the routing in the FPGA.  I did not really play around with the modulation much before tearing it apart, so I'm not really sure what it's capable of, at least in terms of one channel modulating the other one.  A bit idiotic if they did it that way, but whatever. 

[Cyber7]

Have you verified the front end serial shift registers that operate the relays?

Sorry, I wasn't clear: Have you verified positive control of the relays match my output schematic and logic table, not just the pin routing to the shift regs?

[alex.forencich]

Have you verified the front end serial shift registers that operate the relays?

Sorry, I wasn't clear: Have you verified positive control of the relays match my output schematic and logic table, not just the pin routing to the shift regs?

Ah, I have not done that.  I figured that could be done later once there is a method of driving those pins nicely from the FPGA. 

I just finished soldering a header on to my board so I can use a Bus Pirate to control the FPGA.  Next step is to start building the FPGA side of that link and perhaps look in to some sort of cosimulation interface for testing (control software talks to either the MyHDL simulation or the bus pirate, hopefully without channelling Rube Goldberg too much).   

[Cyber7]

I know what you mean; but sometimes you can't avoid one thing leading to another. I actually had to build one in a freshman competition, with the final stage inflating a Space Shuttle inflatable.

Wouldn't the front digital IO ports make for a nice cosim IF for the BP? Perhaps 4 bits as an I2C channel for C&C, 4 bits direct status and the other 8 for pass-through IO.

[alex.forencich]

I know what you mean; but sometimes you can't avoid one thing leading to another. I actually had to build one in a freshman competition, with the final stage inflating a Space Shuttle inflatable.

Wouldn't the front digital IO ports make for a nice cosim IF for the BP? Perhaps 4 bits as an I2C channel for C&C, 4 bits direct status and the other 8 for pass-through IO.

Well, I removed the resistor arrays from my board so I don't have to muck around with the SoC.  So what I'm planning on doing is just using the bus pirate in SPI mode to talk to the FPGA through the same pins that the SoC would use.  But what I want to be able to do is write a high-level control script in python and be able to test that against not only the design on the actual FPGA through the bus pirate, but also connect it to the MyHDL/Verilog cosimulation through some form of interprocess communication.  I might have to use sockets, not sure at this point.  Right now the digital out port is connected to my MSO7104 so I can send out test signals and look at stuff in real time.  I can certainly forward out the SPI interface and decode it on the scope if need be, and then mix and match other internal signals as necessary.