• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by hamster

  1. hamster

    Dividing in Verilog.

    It may well do, but not knowing *all* the details of what you are doing means I can't offer you useful advice.
  2. Seen the problem. You need to define both o1[0] and o1[1] in your constraints, as o1 is a vector of two signals. At the moment you are trying to attach both signals to the same pin, hence the error. Ditto for o2, o3 and o4.
  3. hamster

    Dividing in Verilog.

    If you are dividing by a constant to can multiply by the inverse. If you only have a small number of different divisors you could consider a lookup table of inverses. Otherwise you need to implement a binary division algorithm yourself, to meet your throughput and latency needs. Division by arbitrary numbers is quite expensive - best avoided if at all possible.
  4. Are you showing us all of the file? What does the top level of your design look like? Do you have any other XDC files in your project?
  5. Oh, found the source of some of the noise, and it wasn't the FPGA (phew). I had inadvertently bodged the output RF filtering capacitor to the wrong side of the output resistor causing it to pull lots of current when switching. A bit more bodging to the correct side and it is now a lot better. Now if I short out the inductors on the DAC's power supply I now see the FPGA noise, and when I remove the short the noise goes away.
  6. So a long time between updates. Board has arrived, has been built and tested - I left off some RF filtering caps on the output.. In 16-bit audio pass-through went well. The CMOD-A7 is quite noisy - there is quite a lot of high frequency spikes and ringing from the FPGA. Event when I split the power supply so the CMOD is powered by a linear bench supply. Turns out a lot of the noise was through the air, not via the PCB or power trace, and due to the high impedance scope.probe. I could probe straight on the ground clip and still see the noise. However, on listening tests it is fine - even at high volumes there is minimal hiss. Move to using 24-bit I2S mode at 48kHz, and it too works well. Last night I wrote written a simple SDRAM memory controller for the CMOD-A7, and it is now storing samples into RAM and playing it back. I might play with some filters over the next few days. I am hHappy enough that I am doing a second version of the board, that has a nicer layout, better grounding and uses electrolytic caps (because that is what audio nerds are supposed to use!) It is quite a fun project to tinker with. All I need is more time alone at home to play the HiFi really loud!
  7. I receive and process serial data in this hack: http://hamsterworks.co.nz/mediawiki/index.php/PmodMAXSONAR It looks for an R character, then takes numeric ('0' to '9' ) that appear after that.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. Anything that uses 0.1" headers is more of a "use on a breadboard for learning/experiments" than a serious module for integration...
  13. 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.
  14. hamster

    I bricked my CMOD-A7

    Success! Now works again plugged directly into the laptop.
  15. 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.
  16. 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.
  17. 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
  18. 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
  19. 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'.
  20. 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.
  21. 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!
  22. 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!
  23. Maybe remove the 'reg' from the Verilog port definition?
  24. I've done it before without issue, and all I can suggest is that you look carefully at your component/module names and especially uppercase / lowercase. Maybe add some code snippets to the thread?