another microZed project

The ZYNQ didn't exist 5 years ago.

No FPGA.

This is our second uZed project. The first one was very well received.

It looks like it will be fast enough.

Den fredag den 27. februar 2015 kl. 21.09.28 UTC+1 skrev John Larkin:

you don't even need the flash chip, we make our own Zynq board. even with an empty flash chip it'll boot of an SD card

and you only need a few megabytes for the first stage bootloader and uboot of the fat partition, the linux root file system is usually on a different partition and in EXT4 format

-Lasse

OK. I couldn't quite tell which side of the transfer (*from* SD card or

Apropos discussion later in the thread, I think FAT32 is the right answer for that SD card, especially if you think the user is going to take it out of your box and plug it into a Windows machine at some point.

If somebody told me I couldn't use FAT32, but I still had to support using it on Windows, my next choice, believe it or not, would be NTFS. This would probably suck for reading the files fast, though... or you'd get the situation where most files would read just fine but one file would randomly involve going off and playing with NTFS for several milliseconds.

If I were outside the US, I might think about exFAT, but in the US, I'd rather not pay the protection money to Microsoft.

The "official" Linux kernel has built on ARM for quite a while now. (In other words, it's part of the source that anybody can get from kernel.org, not from one specific vendor.) There will probably always be some hardware-specific changes to get the kernel to run on a particular CPU. But I suspect most of the Linux kernel is stock, even if it's an older version.

There are even some distributions (Debian is one, probably others) that provide as much of the "full" software stack as they can for ARM. If you have a display, you can run X, Firefox, etc. Probably not interesting for the products you make, but it exists in the world.

This is the part I was originally thinking of. As far as I know, stock Linux doesn't know about FPGAs, so you get to write your own driver for them.

...probably including settling debates about doing something on the ARM side or the FPGA side, and other fun stuff like that.

As a customer (in general), I want as much as I can get in the manual, even if not all of it has to do with getting the thing to run. But I can see someone making the argument that putting all of that in the manual is giving away the secret sauce. I bet the final answer ends up somewhere between "plug it in, green LED comes on" and what you have now.

Sometimes it depends on how smart you think the customer is, and how much you think they will want to push the hardware to do something outside of the original design. Sometimes it depends on who's gonna answer the support phone.

Matt Roberds

Boy, you really missed that one.

What I said still stands. Your board is not all that new a design... at the base level, even if it is 'new', it is a mere respin of the first.

what would be the point of a new board? it would exactly the same parts on it is it basically SOC, power supply, memory and connectors

-Lasse

Hell, the one I posted is an order of magnitude faster, has a bigger base memory, newer kernel support, full circuit disclosure... cheaper... I am sure that integrating an fpga with it would be trivial.

End up costing the same or more, but be far more locally controlled and manageable. Likely cost less, now that I give it a thought...

trivial? what interface would you use to get a high bandwidth, low latency, dma capable interface to/from an FPGA?

buy a board and an FPGA, you'll have spend money and still not have something that can do the same

-Lasse

That's good to know. We weren't sure if there was a second-level boot resident in the flash.

Did you use the gerbers from the Zed web site, for the PC board?

Our volume is low and our product prices are decent, so it doesn't make sense to make our own Zeds now. How many are you making?

uZed is open source, schematic and Gerbers and BOM and everything. It has a ZYNQ SOC with FPGA fabric and dual-core 600 MHz ARMs, and the software tools to connect them. Having the ARMs and the FPGA on the same chip saves a lot of wires and nanoseconds. They bring out about

It's convenient to have the Ethernet, flash, DRAM, USB, and power supplies all worked out, booting Linux right out of the box. Especially nice for products that won't be built in the thousands.

They could do that, but we don't expect it unless the file system got trashed somehow. Most file transfers will be over Ethernet. They can even upgrade our application code, or the FPGA config, that way.

We don't have a driver. We just make a system call to map the FPGA address space into our application space. Then we can r/w registers, or request file reads directly into the FPGA buffers. Easy.

Certainly.

I doubt that anyone would want to clone these products. There's way too much paranoia in this business.

Den fredag den 27. februar 2015 kl. 23.13.43 UTC+1 skrev John Larkin:

No we only looked at them to get an idea of what was needed, our board is bigger (160x160) with ADCs, DACs, USB hub, eMMC, supercap USP, and different isolated interfaces

the intend is hundreds if not more

-Lasse

the "proper" way is to use the UIO driver, it is already included all you need to do is add a few lines to the devicetree with baseaddres, size and interrupt number, then open and mmap uio instead of mem. you don't have to be root to open uio, and it also adds interrupt to userland code, you just do a read() and it returns when there's an interrupt

-Lasse

The quad core could likely perform his entire hard gate scenario in software with a negligible difference.

how is software going to replace a bunch of IOs at 10's of not 100's of MHz?

-Lasse

We have 8 channels of signal processing: DDS clock generators, FIFOs waveform memories, phase shifters, FIR digital filters, summing, serial DAC drivers, PLLs. The main clocks are 64 and 256 MHz. No software, not even in a DSP processor, is going to do that. The two

Hey, I'm just the circuit designer. Whatever my guys are doing, it seems to work. I don't think we wrote a driver as such. We're not using interrupts in the FPGA interface.

I can design hardware forever, but I get depressed if I write code for more than a week or so.