AoE III price lowered another $10

We needed an SoC with dual ARMs, and the Altera parts weren't available. We also needed Ethernet and USB and files and such, so we went with the microZed board, with Linux and all that stuff working. It was a sensible decision, practically our only choice to make a customer happy, but the Vivado tools are about as bad as the old ISE stuff that we abandoned years ago.

Does Xilinx appreciate how their tools are costing them sales? Maybe they don't want small-biz sales, and they are willing to provide the necessary support to their high-volume suppliers when they do have troubles.

The distributors are supposed to support us, but they really can't.

The zedboard hardware is great, and it's fully documented. The Linux hasn't been a problem. The ZYNQ chip itself is fine. The Vivado software is terrible, which we found out as we went along.

Both boxes work, but it was expensive and buggy and fairly frustrating. We decided to move as much functionality as possible out of the FPGA fabric, and into ARM code, so we could understand it and fix things easier. That's not performance optimum, but it works.

I don't know what you mean by that. Are you referring to transmission line behavior, ground bounce, bypassing, jitter, thermal issues, stuff like that? Or something else?

Our PC boards usually work the first time, a single "compile". Ditto mechanical assemblies, chassis and things. They get checked.

A C program may get compiled hundreds of times.

The care that goes into a design is inverse on how easy it is to smoke test and iterate. Bridges and buildings seldom fall down because the builders only have one chance to get it right and the consequences of a bug are very high.

FPGAs are intermediate between PCBs and C programs, typically only a couple of dozen compiles to debug. People could write code that needs fewer iterations, but few do.

Depends on how you look at it, the stuff that goes in the FPGA has probably been simulated lots of times, just like parts of what you put on a PCB has been spice'd several times

-Lasse

Are you so nuts that you don't realize how psychopathic you sound when you rant like the above?

Take two Midol and chill out... you'll feel more like a real woman in a few days >:-} ...Jim Thompson

So which is it? The Zynq is great or the Zynq is crappy? You still haven't explained why you need this as a SOC. Once I recall you saying you simply didn't or couldn't lay out the board that would have a SOC plus memory plus FPGA compared to just memory and FPGA. Was that the real reason or were you blinded to the flaws in the software?

I think it is clear that Xilinx knows exactly what they are doing. The big dollar accounts get lots of hand holding and sell enough chips to make it worthwhile. The small dollar accounts are... small dollars. You are a small dollar account and they don't really care a lot. You know that but wish it to be different. Besides, you bought the things anyway so it didn't cost Xilinx any sales.

So you would be better off buying an ARM board and adding an FPGA daughtercard? I think so. The Zed can't work any better than the software that supports it. I hope you understand that.

All the above. Getting high speed signals from point A to point B is not falling off a log anymore.

You live in a fantasy world. Or perhaps your FPGA designs are very simple. But your understanding of the design process is very limited. The worst part is you don't understand that.

comparing the complexity of an FPGA and an FPGA/SOC is pears and apples

Xilinx always emit a ton of pointless warnings, like if you use buildin blockram that is natively 18bit wide as a 16bit wide RAM you'll get warning that 2 bits are not connected.

With FPGAs you don't change tools, there is only one.

The Zynq is great and there is really no other way to get the same tight integration and bandwidth between an FPGA and an ARM, though afaiu John isn't using much of that

-Lasse

The Zynq is great, the software isn't perfect but it gets the job done. I wouldn't expect a tool that can handle a part with 9 million lookup tables to be simple

yeh, you don't get Xilinx or a distributor to bascilly hire an engineer to work part time on your project unless you buy parts enough to justify that

That is where the Zynq comes in, when point A and point B are both inside the chip all those issues are taken care off

-Lasse

JF and AW don't like women either. A lot of guys don't actually like women. Want them but don't like them.

I never understood that. Women rock.

More psychopaths subterfuge. You're one sick puppy. ...Jim Thompson

The silicon is fine. The CLBs are wider than the Alteras, which can reduce logic depth, but overall it's about a wash. Avnet is offering us some dynamite pricing if we cut over to ZYNQs. As noted, Vivado is awful and we get essentially no support.

You still

Do you have to be so consistantly personal and nasty?

In this case, the uZed had a lot of gnarly stuff all done and working: gb Ethernet, SD card, flash, DRAM, Linux, so it made sense to buy that, since we needed it all.

We've done lots of products with an LPC3250 and an FPGA, and they work. Bit we waste a lot of real estate and BGA balls and nanoseconds connecting the chips, especially a lot of nanoseconds.

With ZYNQ, we're doing a 32-bit register access from the ARM to the FPGA in about 90 ns, not blinding fast but much better than an off-chip async access from the 3250.

Progress happens. Existing parts go EOL. Our next-gen products will have the FPGA and a couple of 600 MHz ARMs on the same chip.

Again, I don't know what you mean. Daughtercard?

Why are you so deliberately nasty?

Sure, I do all that stuff. Down to picoseconds. We seldom have signal integrity problems, essentially never in the microsecond and nanosecond domain. We have had some interesting ground bounce and crosstalk issues on some FPGAs, but we know about that now.

The LVDS receivers in modern FPGAs seem to be excellent r-r comparators, and are if you don't care about jitter and such.

Our big hassle was the interconnect between them, the Axibus stuff.

There is some other interface that the tools can invoke, basically address/data/r/w, which we used on the first product, but it was really slow, on the order of the off-chip LPC3250 and an async interface.

If we do go with the ZYNQ for chip-level applications (namely higher volume products) I suppose my guys will have to get better with the tools. By trial and error, without support, unless maybe we hire some serious consultants to not design chips, but help us understand things. That might work.

Bandwidth between CPU and FPGA is important to us. That's one reason to go SoC, along with the physical considerations. I'd love to see 20 ns register r/w, but the 90 that we are getting isn't bad.

You are just obnoxious for no reason. I decided to ignore you once, but then you seemed to be objective once in a while. The original decision was correct.

Den fredag den 5. juni 2015 kl. 00.44.17 UTC+2 skrev John Larkin:

The learning curves is steep, but once you get the hang of it, It seems quite straight forward like so many other things

Though it is a bit surprising that if you want to simulate a zynq system with AXI you'll have to buy a license for Cadence AXI models from Xilinx

brush up on your google-foo, there is tons of people doing Zynq and making easy to follow guides to get things running

if you need to move lots of data consider bursts, it seems like it is getting the bus that takes time, once you get going it is full tilt

I do direct access to DDR RAM from the PL with an AXI master in the PL, looks like a few 100ns from setting the address until it is ready for data, but then it is one word per clock cycle for the burst

-Lasse

We are currently reading Linux files directly from the SD card into FPGA space. That may be DMA from the ARM side, but we're not sure how the Linux file system actually works. There may be DRAM buffers that we can't see.

We do a lot of C-to-register random accesses, where the DMA setup overhead would be expensive. So fast low-latency raw register access would be nice.

You really are AlwaysWrong, DimBulb.

On Thu, 04 Jun 2015 13:11:39 -0700, John Larkin Gave us:

As requested, I posted a link to an inverter schematic I mentioned last month in that thread just last week, and I think it was even in this very thread. I guess you were sleeping, or I would have received your standard criticism of anything but the actual circuitry. As in your standard MO.

Try again, fool.

On Thu, 04 Jun 2015 13:27:52 -0700, John Larkin Gave us:

On Thu, 04 Jun 2015 14:56:19 -0700, John Larkin Gave us:

My, you are one presumptuous f*****ad.

My, you sure are one presumptuous f*****ad.

You are completely in the dark, and you presumptions here are just one fine example of that fact.