amb5l

Members
  • Content Count

    6
  • Joined

  • Last visited

About amb5l

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have discovered the xpm_cdc_handshake macro ("Bus Synchronizer with Full Handshake") which appears to be a well sorted way to do what I want (to move parallel data from a slow to a fast clock domain, without consuming FIFO resources). I'll try it and report back.
  2. @[email protected] Understood. You're not wrong - I've used FIFOs, in fact I wrote my own hairy controller for an async FIFO on a Virtex-1 about a million years ago; gray coded pointers etc; it was the only way I could get that generation of parts to move data @ 100MHz. I can't remember why I didn't use a FIFO in this design but - given the glacial data rate - the design does function just fine with double syncing between the domains. I think of the arrival of an audio sample in the FIFO as being a bit like an occasional button press - and by the time the FIFO ready status has ripped through the syncing registers, the data is well and truly stable. I think I used multi cycle clock constraints previously rather than asynchronous groups to make this reasoning a bit more apparent. I take your point about vendor specific libraries, and inference. This project started life as an experiment to design yet another clone of the good old 6502 CPU. That design is not up yet, but is nearly ready. I've had to go quite vendor specific to get it to perform (it runs like an original NMOS 6502 clocked at 150MHz). In fact the VHDL is a bit like a schematic converted straight into VHDL. I've developed a few bad habits along the way!
  3. I've developed a few audio and video example designs for the Nexys Video in VHDL and posted them here: https://github.com/amb5l/tyto_project I am planning to expand on the HDMI IP to make it more general purpose, and add DisplayPort eventually. There is more stuff in the pipeline.
  4. @zygot Thanks. I'll go and find it and do as you suggest.
  5. Dan, I appreciate your feedback. audio_axis.vhd moves audio samples from the CPU clock domain (100MHz) to an audio sample rate interface (48kHz). Specifically, it pulls the samples - one at a time - from the AXI Streaming interface of a FIFO that is coupled to the MicroBlaze CPU. The low audio sample rate means timings are very relaxed and it all seems to work fine. Tests on hardware work OK; I've listened to classical music for hours (with the modulation disabled!). I will look at an exhaustive test; the simulation testbench is very basic and does not yet support automated testing. -Adam
  6. Hi all, I've developed a few audio and video example designs for the Nexys Video in VHDL and posted them here: https://github.com/amb5l/tyto_project I am planning to expand on the HDMI IP to make it more general purpose, and add DisplayPort eventually. There is more stuff in the pipeline. Grateful for any feedback.