rnelsonee

Members
  • Content Count

    13
  • Joined

  • Last visited

About rnelsonee

  • Rank
    Member

Recent Profile Visitors

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

  1. @[email protected] Just for closure, thanks again - it looks like I got it. I talked to the other engineer and he also figured I was creating a problem where there wasn't one: he said he'll just delay the data so it's mid-clock and I can just use two D flip-flops, which is your solution.
  2. @[email protected] Haha, yeah, I like that idea - it's similar to what I first tried - just treating it like any old signal. I must have been using a rising_edge(my_clk) somewhere though because of those warnings I got (I didn't 'specify' that the signal coming in was a clock in any special way, so I guess the implementer just knows I'm using it as a clock by seeing such rising_edge statements). I'll see if I can work your idea into my code - my code is all VHDL and broken into components, so I'll have to play with it for a while. I actually have 3 components currently based on this slower clock,
  3. @hamster, Thank you for that post! I just had my weekly status meeting and I mentioned to the engineer working on the board going into mine that I wasn't going to use the clock he's providing and I don't think that was what he wanted to hear. I put in a new bufg call like so i_bufg: bufg port map (i => CLK100MHz, o => CLK100MHz_buffered); i_bufg2: bufg port map (i => my_clk_ext, o => my_clk_int); but am still getting place errors for poor routing. I don't know why it's so hard to just find a suitable clock pin - it seems like my dev board just wasn't designed for it.
  4. @[email protected], Thank you for the response. I'd assumed that was not good design since it's not a multiple. For those who find this in the future, here is some GPL code in which you provide the ratio of clocks (256/3125 in my example) and it generates a clock. And sure enough, it's working! The clock drift in simulation worries me, but I guess that's just how it is - the drift corrects in time. And that link makes for some good reading. I think I'm okay with my buffer, but with my terribly newbie assumption above, maybe I'm making a wrong assumption here too. But the 8MHz process re
  5. So I must admit I'm more a software guy than a hardware guy, so hopefully this is an easy one. I want to read in bits on pins at 8.192 MHz, buffer them, and send them out on Ethernet via UDP. Ethernet requires 50 MHz and 25 MHz (not a multiple of 8.192 MHz). I have everything working in simulation, and even in the hardware realm by using the Ethernet clock for my fake data (I just have a counter that counts to N*(25/8.192) instead of counting to N before sending the packet, sending N bits). It's based off the excellent ArtyEthernetTX project which has this for line 1 of the XDS # Cloc
  6. To anyone that sees this in the future: My issue was with TLAST. I had it high, and my Custom IP sent out 4 bytes at a time. This limited the DMA to only give out 4 bytes at a time. By only asserting TLAST once every N bytes (you can't keep it at 0, despite the AXI-S spec saying it's optional) the DMA will read back N bytes. This thread links to a custom IP you can use to generate TLAST for you which sits between the FIFO and the DMA so your Custom IP doesn't need to do it.
  7. @[email protected] Thanks again for continuing to reply. And yeah, I'll see if that can work. I'm taking data (1000 bytes or so), throwing a few bytes of header onto it, and sending it over Ethernet. Since I'm only getting 4 bytes per function call from DMA, there doesn't seem to be any advantage to DMA. I figured the main purpose of a DMA was to allow me to use a pointer to grab a chunk of data, but that doesn't seem to be the case - I guess it just saves some processing cycles. If the FIFO can give me a few hundred bytes per function call, I'll use that. I assumed there was no way in the
  8. So it looks like enabling unaligned transfers didn't solve the issue: I'm still only transferring 4 bytes at a time. I really thought that was going to be it. Backing up a bit - is the DMA even required? Is there a way to just read the AXI data from the FIFO?
  9. Oh, hah, I should have mentioned the printf's are just for debugging. In my real program, this all goes out on a UDP port. This program for this post is just to help me get data fast enough - once it works I'll put this code into my other code, without printf. Thank you for the tips - the Allow Unaligned Transfers certainly looks like it might have been the issue - I'm regenerating the bitstream now. And the 0.2Mhz was lousy terminology on my part - the signal from the DMA down to the FIFO saying it was ready happens at about 0.2MHz - it's not a clock or anything. It's just that the "I'm
  10. Hello all, I am trying to stream data from a Custom IP, right now it's just a counter running at 8MHz, to a FIFO, to DMA. This is an image of the design. But the DMA and FIFO only ask (TREADY/WREADY) for data about 0.2 MHz. I'm sure it's because my code is only getting 4 bytes at a time from DMA, so even in a simple loop it's not fast enough. My question is hopefully an easy one: with something like XAxiDma_SimpleTransfer(&AxiDma,(u32) RxBufferPtr, MAX_PKT_LEN, XAXIDMA_DEVICE_TO_DMA); I should be able to have an array of size MAX_PKT_LEN ready to use (I'm just trying to
  11. Awesome, thank you for your help, that was perfect. I was worried because the left side of the AXI GPIO block was the slave AXI, and the HDL-facing interface was on the right, indicating output. But I think I can just make those inputs in the C code. But I'll go ahead and work on making a custom IP. For now I can access buttons via XGpio with your code (changed 0xff00 to 1) and see things change in a Terminal. So that's a good step. For those checking in the future, this tutorial shows how to write HDL and just use a port map to interface with the generated code. Then that becomes a fast
  12. @artvvb Thank you very much for you help. The 'Add Module' is a neat feature! Although to be honest, I couldn't figure out where to put my outputs on the block diagram (type mismatch between my signals out and GPIO bus). But I'll take a step back on just focus on getting data up first. Right now I added an AXI GPIO block and configured it to look at the shield pins on the Arty, so I'm hoping that means I can just poll data at a high enough rate (it's actually ~8 MHz, I was mistaken). I did notice when creating my own IP, it seems like it just created a boilerplate HDL code rather tha
  13. Hello all, I've been reading up on this for a few days, and I see a lot of details, but I want to make sure I have this right: I have some digital data coming in on a wire, and I just want to queue it up and package it and send it as a UDP packet to a computer. I was thinking an Arty board can be used for this, so that's on order. I have the input coming in, and can write VHDL if needed to to help with timing. I'm realizing as I write this I might not even need VHDL, but my data is coming in several kHz, so maybe I need to write VHDL to handle that. I would use the Arty tutorial