Re: [ARTIQ] [RFC] remove output event replacement feature
Good points; I understand the issue better now. I'm OK with removing this feature. Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Wed, Nov 23, 2016 at 3:29 PM, Robert Jördens <r...@m-labs.hk> wrote: > On Wed, Nov 23, 2016 at 9:16 PM, Jonathan Mizrahi <jmizr...@umd.edu> > wrote: > >> leads to overhead and is unergonomic/unaesthetic. > > > > Can you clarify how you find this unaesthetic? From the perspective of an > > ARTIQ user, having to check for zero pulse lengths everywhere seems to > > create far more unaesthetic programs. > > You would obviously not do that every time but inside the pulse() method. > > The implementation is unaesthetic. And the behavior is not all that > obvious and intuitive: close-together events do raise a collision > while actual coincident events sometimes do not (depending on the > channel and on the event). > > > I also second Daniel's point -- we often scan pulse durations starting at > > zero. > > Zero length pulses can be worked around. Do you rely on being able to do > this: > > ttl.pulse(1*us) > ttl.pulse(1*us) > > Also, for some perspective, nobody seems to want to set the frequency > of a DDS twice at the same time. > > -- > Robert Jördens. > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
> > leads to overhead and is unergonomic/unaesthetic. > Can you clarify how you find this unaesthetic? From the perspective of an ARTIQ user, having to check for zero pulse lengths everywhere seems to create far more unaesthetic programs. I also second Daniel's point -- we often scan pulse durations starting at zero. Jonathan ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] shared SPI clock
Yes, there are CS lines, and I can use them, if I physically short the data lines. As it appears I have to short them to avoid having to make a bunch of changes, I would rather virtually short them in software. How do you recommend I do that? Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Fri, Oct 28, 2016 at 11:43 AM, Slichter, Daniel H. (Fed) < daniel.slich...@nist.gov> wrote: > Are there no chip select lines on these DDS chips? If there are, use > them. If there are not, use a mux/demux chip instead of trying to hack up > something atrocious in the gateware. > > > > *From:* Jonathan Mizrahi [mailto:jmizr...@umd.edu] > *Sent:* Friday, October 28, 2016 9:30 AM > *To:* Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov> > *Cc:* Sébastien Bourdeauducq <s...@m-labs.hk>; artiq@lists.m-labs.hk > *Subject:* Re: [ARTIQ] shared SPI clock > > > > Yes, I know how SPI and chip select lines work. The fact remains that I > have sitting in front of me a board with two chips on it, which have > separate data lines and a common clock line. This was done because the > board designer wanted to preserve the ability to write to both chips at the > same time. He used a common clock line because he wanted to save a pin, and > the SPI clock is on all the time and has the same frequency so why not. My > point was that I was willing to give up the ability to do simultaneous > writes if it meant that I could easily control both channels via ARTIQ. I > could, I suppose, just short the two data lines and use SPI "correctly." I > would prefer, though, a software solution, as I really don't want to modify > my hardware. > > > Jonathan Mizrahi > Research Scientist > Joint Quantum Institute > University of Maryland > 301-314-1903 > > > > On Fri, Oct 28, 2016 at 11:10 AM, Slichter, Daniel H. (Fed) < > daniel.slich...@nist.gov> wrote: > > I have a two channel DDS board in which the DDSs have separate signal > lines but a common clock line. I am OK with only talking to one of them at > a time. What is the easiest way to implement the mux/demux you suggest? > When I declare the SPI bus I need the mosi/miso subsignals to not be > specific pins, but rather be determined by a mux internal to the FPGA. How > do I do that? > > > > This is the purpose of the chip select line(s). Most chips that have SPI > communications have a chip select line (sometimes named something > different) that controls whether they listen to or ignore data on the MOSI, > and whether they write to MISO. The ARTIQ SPI system allows you specify > any number of chip select lines along with an SPI bus at bitstream compile > time. You can also just use regular RTIO channels to do chip select > manually if you prefer. So your SPI bus on ARTIQ has one clock, one MISO, > one MOSI, and multiple chip select lines. You route the same CLK/MOSI/MISO > to all of your DDS chips, and then each chip gets its own chip select > line. > > > > If the chips don’t have actual chip select lines on them, you can use an > analog switch or mux/demux chip. There are essentially infinite options > for how to do this; check out http://www.ti.com/lsds/ti/ > analog/switches-multiplexers/overview.page for example to see a bunch of > options. > > > > > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] shared SPI clock
Yes, I know how SPI and chip select lines work. The fact remains that I have sitting in front of me a board with two chips on it, which have separate data lines and a common clock line. This was done because the board designer wanted to preserve the ability to write to both chips at the same time. He used a common clock line because he wanted to save a pin, and the SPI clock is on all the time and has the same frequency so why not. My point was that I was willing to give up the ability to do simultaneous writes if it meant that I could easily control both channels via ARTIQ. I could, I suppose, just short the two data lines and use SPI "correctly." I would prefer, though, a software solution, as I really don't want to modify my hardware. Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Fri, Oct 28, 2016 at 11:10 AM, Slichter, Daniel H. (Fed) < daniel.slich...@nist.gov> wrote: > I have a two channel DDS board in which the DDSs have separate signal > lines but a common clock line. I am OK with only talking to one of them at > a time. What is the easiest way to implement the mux/demux you suggest? > When I declare the SPI bus I need the mosi/miso subsignals to not be > specific pins, but rather be determined by a mux internal to the FPGA. How > do I do that? > > > > This is the purpose of the chip select line(s). Most chips that have SPI > communications have a chip select line (sometimes named something > different) that controls whether they listen to or ignore data on the MOSI, > and whether they write to MISO. The ARTIQ SPI system allows you specify > any number of chip select lines along with an SPI bus at bitstream compile > time. You can also just use regular RTIO channels to do chip select > manually if you prefer. So your SPI bus on ARTIQ has one clock, one MISO, > one MOSI, and multiple chip select lines. You route the same CLK/MOSI/MISO > to all of your DDS chips, and then each chip gets its own chip select > line. > > > > If the chips don’t have actual chip select lines on them, you can use an > analog switch or mux/demux chip. There are essentially infinite options > for how to do this; check out http://www.ti.com/lsds/ti/ > analog/switches-multiplexers/overview.page for example to see a bunch of > options. > > > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] shared SPI clock
OK, thanks for confirming. I have a two channel DDS board in which the DDSs have separate signal lines but a common clock line. I am OK with only talking to one of them at a time. What is the easiest way to implement the mux/demux you suggest? When I declare the SPI bus I need the mosi/miso subsignals to not be specific pins, but rather be determined by a mux internal to the FPGA. How do I do that? Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Fri, Oct 28, 2016 at 9:03 AM, Sébastien Bourdeauducq <s...@m-labs.hk> wrote: > On Friday, October 28, 2016 08:49 PM, Jonathan Mizrahi wrote: > >> In the platform extension file, when I specify the SPI buses, there is a >> clock subsignal "clk." If I want to have multiple SPI buses that share >> the same clock, I'm going to need to reference the same clock subsignal >> in each bus, which means that that specific pin will appear multiple >> times in the file. Will this cause any problems? >> > > Yes. There will be multiple drivers for the same FPGA pin, and the FPGA > tools cannot do anything reasonable with that. > > Do I need to do something else to have a shared SPI clock? >> > > The code assumes one clock per bus. There would be a bit of work to do. If > you are using the SPI devices one by one, I suggest putting them all on a > single RTIO channel and mux/demux MISO/MOSI. > > Sébastien > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] shared SPI clock
In the platform extension file, when I specify the SPI buses, there is a clock subsignal "clk." If I want to have multiple SPI buses that share the same clock, I'm going to need to reference the same clock subsignal in each bus, which means that that specific pin will appear multiple times in the file. Will this cause any problems? Do I need to do something else to have a shared SPI clock? Jonathan ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] 3.3 V I/O on kc705
Thanks! I assume this is the part I need to buy? http://www.ti.com/tool/usb-to-gpio The ARTIQ manual doesn't say anything about removing and replacing the J65 jumper, which the kc705 manual talks about (p. 74). Is this unnecessary? Also, are all of the I/O pins on the FMC connectors in HR banks (and thus able to go to 3.3 V)? I could not find this clearly stated anywhere. On Mon, Sep 19, 2016 at 7:08 PM, Slichter, Daniel H. (Fed) < daniel.slich...@nist.gov> wrote: > To expand, the VADJ rail supplies the output stages for the KC705 I/O > banks connected to the FMC connectors, so if you want to drive things using > LVCMOS or LVTTL 3.3V logic, you will have to program the VADJ rail to > supply the necessary voltage. It’s very straightforward; instructions are > on the ARTIQ manual site below. > > > -Original Message- > > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > > Jördens > > Sent: Monday, September 19, 2016 4:57 PM > > To: Jonathan Mizrahi <jmizr...@umd.edu> > > Cc: artiq@lists.m-labs.hk > > Subject: Re: [ARTIQ] 3.3 V I/O on kc705 > > > > On Mon, Sep 19, 2016 at 9:36 PM, Jonathan Mizrahi <jmizr...@umd.edu> > > wrote: > > > see LVTTL IOStandards, which means they're already operating at 3.3 V. > > > This is why I'm confused about what I need to do to work at 3.3 V off > > > the FMC connector. > > > > https://m-labs.hk/artiq/manual-release-2/core_device.html#vadj > > > > -- > > Robert Jördens. > > ___ > > ARTIQ mailing list > > https://ssl.serverraum.org/lists/listinfo/artiq > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] 3.3 V I/O on kc705
Hello, I would like to operate peripherals on the kc705 FMC HPC connector at 3.3 V, both input and output. Can this be achieved by just setting the IOStandard to LVCMOS33 in the fmc_adapter_io list in the gateware? I ask because the kc705 manual states that all the I/O voltage rails are set to 2.5V by default, including the FMC voltage rails. It also says that to change FMC_VADJ to 3.3 V, you have to remove a jumper and reprogram some TI controller. However, in the artiq gateware directory (e.g. nist_qc1.py), I see LVTTL IOStandards, which means they're already operating at 3.3 V. This is why I'm confused about what I need to do to work at 3.3 V off the FMC connector. Thanks, Jonathan ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] SERDES pin restrictions
Hello, How do I determine what FPGA pins on the KC705 FMC HPC connector are capable of being used for the high resolution serdes TTL in/outs? I could not find this information in the SelectIO resources guide from Xilinx, in the section for ISERDESE2 and OSERDESE2. Can all general I/O be routed as SERDES pins? Also, does the clock pin on an SPI bus need to be a clock capable pin on the FPGA? Thanks, Jonathan ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] connecting to KC705
Robert, Thanks for the recommendations, I solved the problem. It turned out that the problem was that I needed to have SW13 set to 1. It had been set to 00101. In that configuration, I could not connect to the board over ethernet or serial. As a side point, I had it set to 00101 based on this information from Xilinx: http://www.xilinx.com/support/answers/50079.html, after originally being unable to connect to the board over JTAG at all. I would like to be able to connect pins of the KC705 to a scope so that I can write and test programs. I have an FMC debug card from Xilinx (HW-FMC-XM105-G), but I need to know how to map a TTL from the device database to a physical FPGA pin. How do I do that (and how do I see the current mapping)? I see the RTIO channel mappings in the manual, but that doesn't tell me what the physical pin is. Thanks, Jonathan From: Robert Jördens [r...@m-labs.hk] Sent: Wednesday, May 25, 2016 4:48 PM To: Jonathan Mizrahi Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] connecting to KC705 Hey Jonathan, On Wed, May 25, 2016 at 10:34 PM, Jonathan Mizrahi <jmizr...@umd.edu> wrote: > I get "socket.timeout: timed out" (together with a long traceback). What am I > doing wrong? A couple things you can check: Are you supplying _that_ device_db.pyon to artiq_run? Does it blink its LED three times after booting? Does it respond to pings (at that IP address)? If you connect the serial console (next to the jtag-over-usb connector) and look at it during boot (using flterm, minicom, miniterm.py, hyperterm... settings are 115200 baud, 8 bits, no parity, 1 stop bit) what does it say? -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] connecting to KC705
Hello,
I am having trouble running artiq on the KC705. I am going through the
installation instructions, and I believe I have successfully flashed the
bit files. I then flashed the mac address and IP, using the commands:
> artiq_mkfs flash_storage.img -s mac 1A:2B:3C:4D:5E:6F -s ip 192.168.0.16
> artiq_flash -f flash_storage.img proxy storage start
This appeared to work correctly. I then created the file led.py, and
edited the comm entry of device_db.pyon to read:
"comm": {
"type": "local",
"module": "artiq.coredevice.comm_tcp",
"class": "Comm",
"arguments": {"host": "192.168.0.16"}
}
When I then run:
> artiq_run led.py
I get "socket.timeout: timed out" (together with a long traceback). What
am I doing wrong? Are there specific jumpers I need to set on the board
to enable communication, that would not be set by default?
Thanks,
Jonathan
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] installing ARTIQ
Ah, adding the dev channel allowed me to install it. The installation instructions say that the dev channel is only necessary to use the development version of ARTIQ, so I had not added it. Where is the required FPGA support code, if it's not in the OpenOCD releases? What do you think is the fastest way to get to the point of controlling the KC705 board? Thanks for the help! Jonathan -Original Message- From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk] Sent: Tuesday, March 15, 2016 10:49 PM To: artiq@lists.m-labs.hk Cc: Jonathan Mizrahi <jmizr...@umd.edu> Subject: Re: [ARTIQ] installing ARTIQ Hi, On Tuesday, 15 March 2016 6:32:19 PM HKT Jonathan Mizrahi wrote: > I am trying to get ARTIQ installed on a Windows system using the KC705 > board, following the instructions > here<http://m-labs.hk/artiq/manual/installing.html>. This has proven > difficult and frustrating (and not yet successful), so I thought I > would share what problems I've had. First, I installed 64 bit > Anaconda, and then attempted to install the ARTIQ package using the "conda > create" command. > This repeatedly returned an error that the specified package was not > available for win-64. My guess is you forgot to add the dev channel. Do this: conda config --add channels http://conda.anaconda.org/m-labs/channel/dev If that does not help, please post the exact commands you typed and the exact error messages you received. The conda packages are supposed to work correctly on Windows, in fact we automatically test them on our CI server: http://buildbot.m-labs.hk/builders/artiq-win64-test OpenOCD is indeed a bit difficult to install right now, and may need to be built from source (this is probably easier on Linux) as the releases do not contain the required FPGA support code yet. We could look into providing conda packages for it. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] installing ARTIQ
Hello, I am trying to get ARTIQ installed on a Windows system using the KC705 board, following the instructions here<http://m-labs.hk/artiq/manual/installing.html>. This has proven difficult and frustrating (and not yet successful), so I thought I would share what problems I've had. First, I installed 64 bit Anaconda, and then attempted to install the ARTIQ package using the "conda create" command. This repeatedly returned an error that the specified package was not available for win-64. It did not matter which ARTIQ package I chose. The same was true after installing 32 bit miniconda, with the error now reading that the packages were not available for win-32. Running "anaconda search -t conda artiq" shows me a list of ARTIQ packages and on which platforms they are supported. All of the main ARTIQ packages list "Platforms" as "None-None." This suggests that none of the ARTIQ packages would install via the "conda create" mechanism, on any operating system, which confuses me. At this point I considered trying to install from source. However, the instructions to do so rely on Linux tools and assume a Linux system. Next, the installation instructions ask me to "install OpenOCD," with no other comment. This appears to be non-trivial. How, exactly, do I install OpenOCD on Windows? My attempts to do so using Windows binaries available online all gave me errors that I needed a .cfg file, and needed to specify a debug adapter. I assume these things are specific to a given FPGA? Are there any guidelines as to how to do this? It would be enormously helpful to me (and, I suspect, many other potential ARTIQ users) if true step-by-step installation instructions were provided for Windows. Any help in getting up and running with the KC705 would be very appreciated. Thanks, Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
