Is there a One-shot capture mode ? - where SW arms the capture, and that HW waits for the next external edge, to do the allocated capture ? (Basically, a D-FF, that should be able to capture adjacent Cells too )
Yes. That exists, already. You can capture states, highs, lows, or cycles. You can also capture A-rise to B-rise.
Does that include ARMED capture ? - ie where you want the next edge, and only the next edge, so a single capture per software load(arm) is needed.
Is there a One-shot capture mode ? - where SW arms the capture, and that HW waits for the next external edge, to do the allocated capture ? (Basically, a D-FF, that should be able to capture adjacent Cells too )
Yes. That exists, already. You can capture states, highs, lows, or cycles. You can also capture A-rise to B-rise.
Does that include ARMED capture ? - ie where you want the next edge, and only the next edge, so a single capture per software load(arm) is needed.
Yes. You'd cycle DIR low and then wait for the first sample.
Question, will the smart-pin IO instructions be fast enough to capture the value of a free running counter every 50ns? Will there be enough instructions left between IO instructions to do a subtract, an array index, and an add? (i.e. the fastest portions of the photon counting system in the LIDARs I work on. currently done with an FPGA)
Could be tight, above, Chip says it streams nibble wide, so 8 SysCLKS, so that just packs into 160MHz. and gives you a 8 CLK REP loop for the housekeeping.
@JMG and Chip: Thanks for the response! I'll admit my applications is rather obscure, but it sounds like the Propeller 2 will be "close enough" to photon-count if the research group I work for ever make a super cheap lidar. I expect I'll have my FPGA solution finished before the Prop 2 goes on sale, but right now I wish the Prop2 was already on sale. Getting the photon counts from an FPGA to a PC reliably and fast enough is just HARD with modern interfaces. (why did ISA have to die!)
... Getting the photon counts from an FPGA to a PC reliably and fast enough is just HARD with modern interfaces. (why did ISA have to die!)
Did you look at the FTDI FT600 ? USB 3.0 Super speed
I'm hopeful the P2 pin support will manage the FIFO handshake of that, but a FPGA should do it easily.
... Getting the photon counts from an FPGA to a PC reliably and fast enough is just HARD with modern interfaces. (why did ISA have to die!)
Did you look at the FTDI FT600 ? USB 3.0 Super speed
I'm hopeful the P2 pin support will manage the FIFO handshake of that, but a FPGA should do it easily.
FTDI's fastest USB2.0 chip would be fast enough, but USB isn't quite reliable enough on Linux. (though this is still my backup plan) The USB buss/drivers go haywire after 3-6 months of continuous running, forcing us to restart the PC. The old PCI boards on the other hand, run forever once they're setup. Hence my desire to target PCIe or Ethernet, and my frustration with the complexity. Also, frustration with the #@(*! licensing costs of all the "turn key" FPGA drivers. (for a 5-20 part project like mine, licensing fees could easily dominate the project cost plus the "turn key" solutions look nearly as complex as DIY!)
PLX makes good stuff. Our last data-system used a PLX chip but the PEX8311 with a 337 ball BGA package and >300 page datasheet does not impress me as a "simple" solution. (we don't do BGA assembly in the building)
While searching for PCIe bridges, I did run across a little Chinese company making a PCIe to 4 usb and ISA bridge in a QFP package. It was very tempting, but almost certainly had a lowest bidder driver full of bugs. Another good option I found was a BeagleBone Black. It can configure it's IO pins as a "microprocessor buss" and the PRUs should keep data flowing fast even if DMA didn't work out. Didn't want to add another Linux distribution to the final system if I could avoid it though. (oh and xillybus.com/ made me think direct from the FPGA would be "easy")
In the end I settled on an easily extendable FPGA host card with PCIe built in and a plug-in Ethernet module. EnterPoint Raggedstone 5 It gives me fall-back options, so I'll get a working product eventually. Still wish I could use a Propeller 2 instead! That would be much easier that VHDL and FPGA data-sheets. (i.e. the data sheet for the Spartan6 IO pins is 98 pages long!)
.... Still wish I could use a Propeller 2 instead! That would be much easier that VHDL and FPGA data-sheets. (i.e. the data sheet for the Spartan6 IO pins is 98 pages long!)
P2 to Ethernet is still not confirmed, but hopefully the Streamer / Smart pins will be able to talk to a PHY - it's only a 25MHz clock nibble wide.
Is that fast enough for what you need ?
I wonder when someone will offer a HyperBUS Ethernet peripheral ?
FTDI's fastest USB2.0 chip would be fast enough, but USB isn't quite reliable enough on Linux. (though this is still my backup plan) The USB buss/drivers go haywire after 3-6 months of continuous running, forcing us to restart the PC.
Is that a fundamental Linux core issue, or do some drivers do this (FTDI?) ?
Seems a pretty significant short fall, and not easy to qualify.
P2 to Ethernet is still not confirmed, but hopefully the Streamer / Smart pins will be able to talk to a PHY - it's only a 25MHz clock nibble wide.
Is that fast enough for what you need ?
100Mbps is plenty for my application. But I'd expect the Prop2 streamer to handle the GMII interface just fine, so MII should be a cake-walk. Having the data clock sourced from the PHY chip might be an issue. (btw, I think the prop2 should be able to do 100baseT directly with 4-IO pins and some creative transformer biasing)
FTDI's fastest USB2.0 chip would be fast enough, but USB isn't quite reliable enough on Linux. (though this is still my backup plan) The USB buss/drivers go haywire after 3-6 months of continuous running, forcing us to restart the PC.
Is that a fundamental Linux core issue, or do some drivers do this (FTDI?) ?
Seems a pretty significant short fall, and not easy to qualify.
At the moment I'd blame FTDI, but the programmer I work with is none too impressed with the Linux USB stack either. Fundamentally we've had too many higher priority bugs to squash, so the intermittent bugs get ignored and worked around.
FTDI's fastest USB2.0 chip would be fast enough, but USB isn't quite reliable enough on Linux. (though this is still my backup plan)
If you need back-ups, then maybe the FT90x MCU is a better fit - that has HS USB and 10/100 Ethernet.
Comes in QFN/QFP packages
Sounds nice, can I get it pre-flashed to provide a fifo interface to USB or Ethernet depending on which cable is connected? If not, it's just another time sink of unknown final functionality.
...
Sounds nice, can I get it pre-flashed to provide a fifo interface to USB or Ethernet depending on which cable is connected? If not, it's just another time sink of unknown final functionality.
Anything will be a time-sink, some more than others.
Contact FTDI ? - they do have an Ethernet example posted (and also a Camera example - Camera is 25MHz, 8b, 2k FIFO parallel )
At the moment I'd blame FTDI, but the programmer I work with is none too impressed with the Linux USB stack either.
My experience with USB hardware (PC USB ports), no matter the software stack managing it, is it is prone to going into various bad states from most forms of noise. Resocketing the attached device often recovers it but obviously that is not an ideal solution even for a workaround.
Comments
Yes. You'd cycle DIR low and then wait for the first sample.
"Flexpin"
FLP
FLEP (FLOP)
@JMG and Chip: Thanks for the response! I'll admit my applications is rather obscure, but it sounds like the Propeller 2 will be "close enough" to photon-count if the research group I work for ever make a super cheap lidar. I expect I'll have my FPGA solution finished before the Prop 2 goes on sale, but right now I wish the Prop2 was already on sale. Getting the photon counts from an FPGA to a PC reliably and fast enough is just HARD with modern interfaces. (why did ISA have to die!)
Marty
Did you look at the FTDI FT600 ? USB 3.0 Super speed
I'm hopeful the P2 pin support will manage the FIFO handshake of that, but a FPGA should do it easily.
FTDI's fastest USB2.0 chip would be fast enough, but USB isn't quite reliable enough on Linux. (though this is still my backup plan) The USB buss/drivers go haywire after 3-6 months of continuous running, forcing us to restart the PC. The old PCI boards on the other hand, run forever once they're setup. Hence my desire to target PCIe or Ethernet, and my frustration with the complexity. Also, frustration with the #@(*! licensing costs of all the "turn key" FPGA drivers. (for a 5-20 part project like mine, licensing fees could easily dominate the project cost plus the "turn key" solutions look nearly as complex as DIY!)
Marty
These might help - http://docs.avagotech.com/docs/AV00-0323EN The PEX8311 will be a simple straight bus interface. It a BGA package though - http://www.avagotech.com/products/pcie-switches-bridges/pcie-bridges/pex8311
PLX makes good stuff. Our last data-system used a PLX chip but the PEX8311 with a 337 ball BGA package and >300 page datasheet does not impress me as a "simple" solution. (we don't do BGA assembly in the building)
While searching for PCIe bridges, I did run across a little Chinese company making a PCIe to 4 usb and ISA bridge in a QFP package. It was very tempting, but almost certainly had a lowest bidder driver full of bugs. Another good option I found was a BeagleBone Black. It can configure it's IO pins as a "microprocessor buss" and the PRUs should keep data flowing fast even if DMA didn't work out. Didn't want to add another Linux distribution to the final system if I could avoid it though. (oh and xillybus.com/ made me think direct from the FPGA would be "easy")
In the end I settled on an easily extendable FPGA host card with PCIe built in and a plug-in Ethernet module. EnterPoint Raggedstone 5 It gives me fall-back options, so I'll get a working product eventually. Still wish I could use a Propeller 2 instead! That would be much easier that VHDL and FPGA data-sheets. (i.e. the data sheet for the Spartan6 IO pins is 98 pages long!)
Is that fast enough for what you need ?
I wonder when someone will offer a HyperBUS Ethernet peripheral ?
Is that a fundamental Linux core issue, or do some drivers do this (FTDI?) ?
Seems a pretty significant short fall, and not easy to qualify.
If you need back-ups, then maybe the FT90x MCU is a better fit - that has HS USB and 10/100 Ethernet.
Comes in QFN/QFP packages
100Mbps is plenty for my application. But I'd expect the Prop2 streamer to handle the GMII interface just fine, so MII should be a cake-walk. Having the data clock sourced from the PHY chip might be an issue. (btw, I think the prop2 should be able to do 100baseT directly with 4-IO pins and some creative transformer biasing)
At the moment I'd blame FTDI, but the programmer I work with is none too impressed with the Linux USB stack either. Fundamentally we've had too many higher priority bugs to squash, so the intermittent bugs get ignored and worked around.
Sounds nice, can I get it pre-flashed to provide a fifo interface to USB or Ethernet depending on which cable is connected? If not, it's just another time sink of unknown final functionality.
Contact FTDI ? - they do have an Ethernet example posted (and also a Camera example - Camera is 25MHz, 8b, 2k FIFO parallel )
My experience with USB hardware (PC USB ports), no matter the software stack managing it, is it is prone to going into various bad states from most forms of noise. Resocketing the attached device often recovers it but obviously that is not an ideal solution even for a workaround.
Thanks. I hope you like them. They are definitely something new to Prop2.
This was the last chunk of development needed to finish the design. Now, it's just making sure we've got a good mix and no bugs.
P123-A9 and DE2-115 are testing code right now.
P.S. GETRND is working nicely now too..
smartpin_serial looks interesting
Super!
I added a few lines to the ROM booter to start up the LFSR. It's very useful for DAC dither mode.
The long road is getting shorter.
Does that sound of excitement Peter mean you are gonna build Tachyon for the DE0 too?
plz
===========================
Single step ok - loads ok
smart_pin_serial.spin - error - @ [color] pinsetm [/color]pm,x
Expect a unique Name, Byte, Word, Long, or assembly instruction
VGA_640_X_480 _ 8bpp error @ dacmode -
Expect a unique Name, Byte, Word, Long, or assembly instruction
smart_pin_pwm.spin - error @ pinsetm - Expect a unique Name, Byte, Word, Long, or assembly instruction
Now I have to see if I'm doing something wrong.