another microZed project

formatting link

formatting link

It's an 8-channel waveform generator that can play big files stored on a micro-SD card.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

What do they cost and what is the sampling rate? Or should I email you.

Steve Roberts

Reply to
sroberts6328

Please tell me that J1 is not for a floppy drive. (It's 34 pins; I counted!)

What are the three sets of six holes between the top two mounting holes for? Just curious.

Is this the one that you were asking about the playback software a month or so ago? (gen/strobe/daemon)?

Matt Roberds

Reply to
mroberds

Look at the piggy back board he put on it and his description and answer your own question.

Reply to
DecadentLinuxUserNumeroUno

Ribbon cable to the front panel.

That's for three rotary hex switches on the bottom of the board, to set the IP address. The customer wants that. Similar to...

formatting link

Yes. It looks like it might work! We can do Linux file reads from the SD card into the FPGA at 19 Mbytes/sec, and we can do 32-bit writes from a tight ARM loop into an FPGA register in 90 ns.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

A bit under $5K, and the DACs are loaded at 2 MHz. Analog bandwidth will be 500 KHz. There are also two ADC inputs, for modulation or summing.

Email me if you want to see a manual.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

I recall you mentioning that for a different product before. I can actually think of a few different motivations for it. If they have a lot of devices, they may not want to navigate slightly different internal-Web-server or console-serial-port interfaces to set an IP address on all of them. DHCP or BOOTP exists, but then if you want to talk to a particular box, you have to figure out which one it is. SNMP also exists, but 1) it requires more coding and 2) if you set the IP address over the network, you eventually have the Bugs Bunny problem (sawing off the tree branch you are standing on). With the switches, they just grab a screwdriver and it's set and guaranteed not to change; if you want to know the setting you just look at the switches.

Do the switches set the bottom 12 bits of the address (like

192.168.[0-15].[0-255] ), or the bottom 4 bits of the last 3 bytes (like 10.[0-15].[0-15].[0-15] ), or something else?
*math* So roughly 44 Mbytes/sec for the tight loop write... about 5.5 Mbytes/channel/sec if you're using all 8 channels.

Matt Roberds

Reply to
mroberds

only 3 switches? I guess you set the subnet?

axi-lite or burst capable?

I access the DDR directly from the PL via one of the axi slave ports, and 90ns is about the time it take to get acknowledge on an address, after that it's a word ever 1-2 clock cycles for the burst length

roughly 400ns for a 16 words

-Lasse

Reply to
Lasse Langwadt Christensen

Yeah. They all look the same!

SNMP

The switches add 12 bits to the base IP address, which is in our ASCII "calibration" file, along with serial number, model, and the actual cal factors. Users can change that file, too, over Ethernet or, if they get tangled, USB.

We plan to do file reads directly from SD card files into the FPGA FIFOs, which are mapped as program space memory. I don't know how Linux handles that (Direct DMA? Cached in RAM? Who knows?) but the 19 Mbytes/sec seems real. The data transfers into the FPGA appear to be

32 bits wide.

We want to run 8 channels at 500K samples/sec, which is 8 MBytes/sec net. Might work.

We fired up the first board today. Power supplies work, Linux boots, and we can read some FPGA registers from an ARM program. No disasters so far. Not bad for Day 1 of a new board.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

I'm not doing the FPGA design (well, just the architecture) but they are doing the full AXI bus, but no DMA engines in the FPGA. AXI sounds like a mild nightmare. Luckily, our FPGA consultant learned AXI on someone else's payroll.

We are throttled by the SD card file reads, so there's probably no reason to do bursty things.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

Den torsdag den 26. februar 2015 kl. 00.43.53 UTC+1 skrev John Larkin:

the basics are not terribly complicated, read and write each have an address bus with a valid/ready, and a data bus with a valid/ready

same type bus is used for filters and such, except they don't need the address path

-Lasse

Reply to
Lasse Langwadt Christensen

For a while now, a lot of rack-mount PCs have come with "identify" LEDs, usually one on the front and one on the back. Their only job in the world is to turn on and off when commanded to (via SNMP or other remote- management protocol). The guy you've dispatched to the server room is meant to call the mothership on the phone; the mothership blinks that light a couple of times so the guy can verify he's about to power down the right server.

Sounds reasonable.

The FPGA FIFO mapping depends on how Xilinx (or whoever) wrote the FPGA driver; I don't think stock Linux provides an implementation for that. If you have the source to the FPGA driver, it probably has the answer.

I was once present for the smoke test of a new board. Apparently a couple of tantalum capacitors had been stuffed backwards, so the smoke test was not successful.

Matt Roberds

Reply to
mroberds

The driver in question is the Linux SD card driver, called by the FAT32 file system code. That's all ARM side, presumably part of the hard IP bought from ARM. The Linux is probably custom to that hardware.

Our FPGA implements a dummy 64 kbyte address space per channel, which is really the FIFO inout; we wrote that. Our file demon app maps that dummy buffer into its program address space, and then requests standard Linux file reads into that space, and the data pours directly into the FIFO. The FIFO output, at the DDS rate, gets filtered and modulated and summed and suchlike mangled and eventually loaded into the channel DAC.

This is simple and should work. If we built a DMA engine into the FPGA, the demon would have to do the file reads into DRAM, and then sic the DMA engine onto that data. I don't see that as being much faster.

There is the hardware, ARM code, FPGA design, and user protocols, with about 5 people working on various bits. I'm the system architect and I have to get it all working together. The unifying thing is the manual, now at rev 7, which is packed with both the usual user stuff and with design internals, FPGA registers, Visio FPGA flow diagrams, all sorts of stuff. Some people think we should strip the internals before we release the manual to customers, but I'm inclined to let them see it all.

Well, we got past that. We also created a design verification document, with a zillion things to test and measure and check off. That's being worked on. It will be a good future reference.

--
John Larkin         Highland Technology, Inc 
picosecond timing   laser drivers and controllers 
 Click to see the full signature
Reply to
John Larkin

Not successful? Didn't it smoke? ;-)

--
Reinhardt
Reply to
Reinhardt Behm

If you are on Linux, you can format the SD chip any way you want that Linux sees and install support for most it doesn't 'see' by default.

Certain file formats read faster from SD on linux. You should experiment to optimize your application.

Samsung seems to make the fastest ones too.

The boot partition on the board's boot chip is usually FAT.

Sometimes FAT16 even.

If you edit a boot text config file from within Windows, you should use a tool like "Notepad+" as it will preserve the linux file format.

Regular notpad messes it up.

Reply to
DecadentLinuxUserNumeroUno

The boot loader that comes with the board assumes the SD car is FAT32. I've talked to real linux jocks (including our prime customer) who think another file format wouldn't be worth the trouble.

We've tried a bunch of SD cards. They seem to top out at around 19 MBytes/sec on big file reads. I din't think the ARM in the ZYNQ has the advanced high-speed interface needed to fully exploit the U3 type flashers.

--
John Larkin         Highland Technology, Inc 
picosecond timing   laser drivers and controllers 
 Click to see the full signature
Reply to
John Larkin

You ain't real bright. The chips are blank when you get them. YOU can have the device format it. Your boot loader memory chip and your data chip should be two physically different devices. If the board is not that way, you picked the wrong board.

If it works better than FAT (and it does), it would be in your best interest to make use of it. For one thing a single failure on a FAT formated chip can cause a loss of the entire volume.

The boot loader "assumes" nothing. The boot loader can be on a ten MB partition. The entire chip can be of a better, more robust, more data safe file system type for the application.

Reply to
DecadentLinuxUserNumeroUno

don't think you have an option, the on-chip ROM bootloader has to load the first stage bootloader from it.

Linux on Zynq uses a compiled devicetree, not a text file

-Lasse

Reply to
Lasse Langwadt Christensen

That board you chose is at least a five year old design. Pretty sad choice with all that is out there.

You really should have spent some more time with this end of your design.

formatting link

That POS you bought... they sure saw you coming... all zero experience and everything. I'll bet it barely is even able to read the file. much less read it fast enough.

Reply to
DecadentLinuxUserNumeroUno

did you miss the part this is an IC with not only and ARM but also programmable logic?

-Lasse

Reply to
Lasse Langwadt Christensen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.