hamster

Members
  • Content Count

    515
  • Joined

  • Last visited

  • Days Won

    79

hamster last won the day on August 2

hamster had the most liked content!

About hamster

  • Rank
    Overly helpful
  • Birthday 08/23/1969

Contact Methods

  • Website URL
    http://hamsterworks.co.nz

Profile Information

  • Gender
    Male
  • Location
    New Zealand
  • Interests
    Electronics, FPGAs, MtBiking, Road Cycling, Linux....

Recent Profile Visitors

6194 profile views
  1. The PMOD Specification res 1.2 mentions 25MHz for low speed ports, and 100MHz for the high speed ports. I have managed to get 400Mb/s through them once (for HDMI RX). But that is only enough for 800x600.
  2. The transceivers are on dedicated pins, and are seldom connected to the HDMI sockets unless the board was expressly designed for video. As mentioned earlier, this isn't a restriction of the FPGA - the FPGA can handle this data rate. It is a restriction imposed by choices made by the development board's designers.
  3. I've done a total of 10.3125 Gbps, or maybe 10.8 GB/s over the four lanes... can't remember if it is 2.7Gb/s or 2.65 Gb/s per lane. It was a while ago... That is just enough for 4k60.
  4. None of these options will deliver 2160p. To do 2160p (and even 1080p) you need hardware specifically engineered for that purpose, not a generic multipurpose development board. The only Digilent board that I am pretty sure could support a 2160p 60hz display is the Gensys2, using the DisplayPort interface. However event that might be restricted to 422 YCC formats (not 444 RGB) 0
  5. Anything that uses 0.1" headers is more of a "use on a breadboard for learning/experiments" than a serious module for integration...
  6. What do you mean by 'handle'? The FPGA fabric could process the video stream, but unless the FPGA transceivers are connected to the HDMI sockets it won't be able to. On the Z7 the HDMI connectors are on the standard I/O pins. Also, HDMI 2.0 is required for that video rate, and the spec isn't openly published.
  7. hamster

    I bricked my CMOD-A7

    Success! Now works again plugged directly into the laptop.
  8. hamster

    I bricked my CMOD-A7

    Wahoo! Success! Thanks for your help @zygot, @D@n & @xc6lx45, and faith that the CMOD wasn't a completely bricked. Last night while I was on the way to bed walked past my bench and had one last try. Plugged the CMOD A7 into a powered USB, and then booted up my Linux PC. Once booted and signed in I cleared the kernel message buffer with a "sudo dmesg -c". I then plugged the hub into the PC, and both FTDI channels channels came up and stayed up. As a test, I then removed and replugged the CMOD to the hub, and had the usual fault happen - both came up, but the JTAG interface disappears. I repeated the process from cold, and got the same results. Conclusion: With at least my invalid image in the flash, the FTDI JTAG interface or driver does not initialize correctly if plugged into a PC directly. By using a powered hub,. and giving the CMOD enough time, BEFORE you connect the hub to your PC, you can restore JTAG functionality. ... phew, I am glad I wasn't in a hurry to break out the soldering iron and hot air.. @JColvin Are any of the back-room team aware of this sort of thing happening and how to work around it? Maybe they could investigate what is going on, publish a process on how to recover and it might save a few warranty claims / product failures. I am sure that there will be people other than me who have experienced this issue.
  9. hamster

    I bricked my CMOD-A7

    Tried multiple cables and power supplies, but no different behavior. I've been investigating playing with the boot mode strapping resistors, as suggested by @zygot & @xc6lx45 but they are 0402 or maybe even 0201, and on the bottom-side of the board. I'ld really need to borrow a friend's microscope, and even then I think I lack the skills for anything but carefully shorting the FPGA signal (not the power side!) to the opposite power rail. Compared to lifting the strapping resistors popping the flash off would be easy.... I might sit on it, and maybe try looking at the Linux layer for the USB equivalent of a SCSI hot-plug/rescan, based on the assumption that the attempt to configure from flash must timeout after a while. Ether that or try connecting the power lines before I connect the data lines, or putting powered a hub toop. Will play again in the weekend if time allows.
  10. hamster

    I bricked my CMOD-A7

    The devices identifies correctly so it looks as if the FTDI is OK. The serial port stays up and active, but the JTAG port only hangs around for a few seconds. It looks to me as though the lack of the FPGA to configure correctly is crashing/blocking the USB JTAG interface. Looking at the schematics the JTAG is only connected to the FPGA, and doesn't connect to the QSPI Flash at all, so I can't see why it won't work, unless the JTAG is blocked while the FPGA is configuring, and this is causing the driver to barf and fail. I wonder if I can remove and reprobe the USB device? I've checked at least the 3V3 rail, and it seems OK. I am half thinking of breaking out the microscope and jumpering the FPGA into JTAG boot mode rather than SPI.... Maybe if all else fails I lift the Flash from the board, program it with a good image and then put it back??? Looks very similar to https://forums.xilinx.com/t5/Other-FPGA-Architecture/device-disconnected-when-programming-FPGA/td-p/768702 and https://forums.xilinx.com/t5/Xilinx-Evaluation-Boards/Digilent-Adept-USB-device-disconnects-immediately/m-p/310301#M12179
  11. hamster

    I bricked my CMOD-A7

    I seem to have bricked my CMOD-A7 while programming the flash. The 'DONE' LED never lights, and the USB JTAG seems to appear for a few seconds then go away again: [ 1382.675956] usb 2-1.3: New USB device found, idVendor=0403, idProduct=6010 [ 1382.675962] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1382.675966] usb 2-1.3: Product: Digilent Adept USB Device [ 1382.675969] usb 2-1.3: Manufacturer: Digilent [ 1382.675972] usb 2-1.3: SerialNumber: 210328A41214 [ 1382.679134] ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected [ 1382.679207] usb 2-1.3: Detected FT2232H [ 1382.679559] usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB0 [ 1382.682361] ftdi_sio 2-1.3:1.1: FTDI USB Serial Device converter detected [ 1382.682427] usb 2-1.3: Detected FT2232H [ 1382.682846] usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB2 [ 1382.697639] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 1382.697675] ftdi_sio 2-1.3:1.0: device disconnected Not sure what I did wrong, but I suspect I failed to set "Under Configuration Modes, select Master SPI x4" Putting a scope on the QSPI flash, I can see the FPGA attempt to read the image. Any hints on how to unbrick? Thanks Mike
  12. hamster

    Large Spectrum Generation

    My first guess would be... Take a pseudo-random stream of +1/-1 values, at about 1/4th your desired bandwidth. Lowpass filter that to half your desired bandwidth. Multiply that by your carrier samples Send that to DAC. Would be easy to do, but spectrum will be 'lumpy'.
  13. Phew... not putting a space for "the perfect frequency" clock isn't a worry anymore, as 12MHz * 64 / 31.25 = 25.576MHz, the required for 48kHz sample rate and this is just within the range of the MMCM block. Most likely has less-than-ideal jitter and noise specs for hi-fi buffs, but should be perfectly adequate for my needs.
  14. I've got a few project ideas around a digital crossover for bi-amped speakers... I had the DACs left over from building a few stereo I2S boards with PMOD interfaces, but found using many of them at once was getting impractical - if I had to tidy my desk I would waste a lot of time connecting things up again when I got back to playing with them. The other reason for these chips is they are really, really dumb and simple to use. No preamp or signal routing to configure, no I2C management needed - just send the correct clocks and they send back the correct data. Dumb parts are also cheap parts - the DACs were $0.50, the ADCs are ~$1.00, the sockets are $0.40, making this around a $20 project... I've just had that pang of "I've sent the board away too early". On thing I should have done is added a few extra pads to allow for strapping resistors on the ADCs to configure them, but is is unclear to me how they will interact with the FPGA's pin's default state while the FPGA is being configured. I should have also have added a 24.576 MHz Oscillator too,... so I could run at 48kHz, not the 46.875KHz I'll be running at from the on-board 12MHz clock. Oh, and then... ... maybe I should have added a version number on the PCB too!
  15. I've just sent a PCB away from manufacture - it will have four stereo ADCs and four stereo DACs for the CMOD A7. Once I have one built I'll have to find a use for it!