search

m-labs / pdq

Pretty darn quick interpolating arbitrary waveform generator
GNU General Public License v3.0
6 stars 3 forks source link

Triggering frames via SPI #10

Closed erickson-nist closed 7 years ago

erickson-nist commented 7 years ago

My understanding is that I should be able to trigger the frames via SPI. As mentioned in my previous ticket, setting the frame via SPI works (though has that weird mod 8 issue), but so far I have only been able to trigger them with a TTL connected to F1. Could you please point me to the right method for doing this? Or has it not yet been implemented?

jordens commented 7 years ago

That should work just fine. Set the trigger bit in the config register and clear it afterwards. Let me know if you'd need a different implementation.

jordens commented 7 years ago

Also the number of frames issue should be fixed. Does the fix not work for you?

erickson-nist commented 7 years ago

I am not 100% sure what you mean by clearing it afterwards. To check if I am understanding correctly, to trigger via SPI and then clear I would do something like the following?

self.pdq0.write_config(clk2x=1, trigger=1, enable=1, aux_miso=1) self.pdq0.write_config(clk2x=1, trigger=0, enable=1, aux_miso=1)

Concerning the number of frames issue, I had not noticed that you committed a fix. By the looks of it that should allow up to 2^32 frames (limited by available memory), correct? I will test that as soon as possible. If you have the updated bitstream already compiled it would speed things up since I have been having issues with misoc/compiling the gateware.

jordens commented 7 years ago

Yes. It should work just like that. I can bake a set of bitstreams. But that should work just fine for you as well. ISE 14.7 with a webpack license and also on windows.

erickson-nist commented 7 years ago

I have now been able to test SPI triggering and things seem to be working. I do have two quick questions:

  1. There is a ~6 us delay between the SPI trigger and the start of the waveform, compared to ~0.5 us for TTL triggering on F1. The SPI command itself takes less than 1 us, so most of that time is not from the signal itself. Does this seem like a reasonable amount of time for the PDQ to interpret the SPI signal and begin the waveform? I admittedly do not know enough about the details of the SPI protocol to have an educated opinion.

  2. Triggering individual boards via SPI is working, but we are wondering how far we can stretch that. Is it possible to trigger individual boards in separate master/slave stacks connected to the same SPI line? I ask because we ordered 1 DAC boards in a 1:2 master:slave ratio. Is it possible to set one stack as boards 0-2, another 3-5, 6-8, etc. and trigger individual boards among those stacks, or do the master boards all need to be set to board 0?

jordens commented 7 years ago

Re the trigger delay: I don't understand where that could come from. Do you have a scope screenshot that shows this (with spi and output)? Otherwise I'll have a look.

Re board address: master/slave and address are independent. What you want to do should work just fine.

erickson-nist commented 7 years ago

Looking further into the trigger delay, it seems like it was just a misunderstanding on my part of how artiq works. Getting everything together on the same scope only shows a 1 us delay.

Have you had a chance to compile the updated firmware?

sbourdeauducq commented 7 years ago

@erickson-nist Install ISE Webpack please.

jordens commented 7 years ago

pdq_v3.0-rc2.zip But you should really figure out how to bake these yourself.