I want Verilog language be used to program UDB Datapath instead of state machine. Even better if digital part is replaced with small FPGA, that would ease acceptance of the PSoC by EE. UDB should have direct access to memory, at last to a small portion of it. UDB frequency responce improved. At least 8 analog blocks. 12-bit DAC, possibility to use it as multiplying DAC. Internal analog Mux. ADC_SAR sampling frequency 2+ MHz. Differential OPAMP. Cortex M4 or better processor, 2-4 cores, 1 Mb RAM for audio/musical applications. Dynamic reprogramming (something like Anadigm's FPAA has).
@odissey1: PSoC 6 is expected to have Cortex M4 + Cortex M0+ cores inside, so that covers half of your last wish ;)
I'm a student, so all my projects still silly, but i would like to have a HS USB, more UDBs, and faster analog peripherals. Almost forgot, at least a tutorial to make PSoC Creator run on wine, i think Creator being Windows only stops PSoCs to be a huge success on the hobbyist market.
Hope PSoC 6 gets available on the first half of the next year, it's on more advance development stage than PSoC 7.
"I want Verilog language be used to program UDB Datapath instead of state machine."
You can program the UDB and datapath using Verilog - there are plenty of application notes about the custom modules that need to be added to your verilog code in order to access the datapath at various widths. I've had trouble with DMA writing/reading to the datapath FIFO properly but otherwise everything seems to work using pure Verilog.
"Cortex M4 or better processor, 2-4 cores," - Does any manufacturer that you know of currently produce a cortex-M with more than two cores? The only fairly popular ones I know of are NXP M4/M0 combo (LPC4300), and Atmel Dual M4 which isn't really for additional power, it's for redundancy in safety critical applications.
"1 Mb RAM for audio/musical applications." - No M4 on the market that I know of has over 192kB RAM. Even the M7 chips I have used in the last year max out at 384kB. This is why external memory peripherals that operate at master clock or master clock/2 were created. The FM4 kit has an extra 16Mb (2MB) PSRAM on it. You should look at the kits Cypress sells for this. They're pretty fantastic and cheap. Variants of the M4 are very capable of handling real-time stereo time domain processing at reasonable sample rates - I've even done spectral processing on the M4 that had fairly good overlap, and minimal delay.
What I want to know is, is my mini-prog still going to work with the M4 and 7 based devices...and if not how long will it take for my Segger J-Link to support them?
Having used PsoC 5+5LP, I think their analog and digital functionality is adequate for all but very large projects. All I read about PsoC 6+7 is their 2nd M0 core, which is not what what I miss urgently. But I take the opportunity to place my personal wish list here - applicable to 5LP as well.
CPU: Early ARM versions excelled in an orthogonal, efficient and universal architecture which allowed clever and dense code - never fully exploited by compilers. To cope with their absent smartness thumb was introduced, but of course showed lots of restrictions (especially regarding r13+14+15) and thus approached the infamous x86, where you have to use special registers for special operations. Other known advanced cpus are avr32 and (good old) pdp11. And why not optimize an embedded (like PsoC) cpu to have, say, 20bit registers? So Cortex M3 is what we get but nothing to rejoice.
UDB: As RA1981 pointed out, the i/o width is somewhat restricted, but in the end, I always managed to tweak my circuits and make them fit. However, the verilog simulation models provided by Cypress (till 2016?) are outdated and suffer from errors (obfuscations?). Anyway, a design ported from simulation to silicon showed errors, which could not be explained or resolved.
Tools: I used Creator up to 3.0+1 on less costly pcs as well, where limited screen resolution and compile speed have to be tolerated. Regarding the latter, I mostly blame the underlying huge and inefficient (even hanging) .net "framework". But in winxp+7+8 times MS did not really get in my way yet. That occurred later when they introduced "updates" to drive me out of xp or even 7 (when I set up a newer faster pc with full-hd display but without 10's features). After months of barely successful install and repair work - instead of PsoC (and getting in touch with friendly and powerful linux os and tools) I decided that this was a more pleasing environment. As long as Cypress does not provide linux-based tools I probably will not start new PsoC jobs.
The package: whatever is inside, they should still provide a variant in TQFP. The gull-wing pins work as little springs and help to relieve thermal stress. The DFN/BGA packages are bound to fail after sufficiently many thermal cycles, since the only stress relieve part is just a tin ball. It would be my last day with the PSOCs if Cypress decides to stop producing gull wing devices. That's exactly the reason I keep away from Xilinx's Zynq, technically a much more potent platform: only BGAs of various shapes.