Green moves to greener pastures

Awwww.   I think Harriet's bubbling enthusiasm must have contributed a lot to Pi's standing in the group.  Such enthusiasm is very infectious.

Fingers crossed that Laurence also has a soft spot for Pi and understands the long-term value of promoting technical education in the community.

I'm hoping that the new boss will focus more on customer service than fashion  - I found HG's 'bubbling enthusiasm' for the next exciting thing less than impressive.

I hope that LB deals with the RPi on its merits (or otherwise)  and wish him luck with the new job.

Michael Kellett

> RS / Farnell certainly aren't doing this for charity.  There's a lot of profit involved

we'll see.  the Q1 2012 financial statements (Feb-Apr) are due around 15 June,

3 days after Bain takes over. 

My intuition is that if there was a lot of profit, Farnell would be paying a lot

of attention to RPi.  But I don't see any indication that they are paying hardly

any attention whatsoever.  Certainly begging them to keep the FAQ, blog,

and download centre current is like pulling teeth, and there is essentially

no administrator participation in these forums, despite lots of #helpme tags.

I don't see any evidence that anyone at Farnell is even thinking about the

hard decisions, such as how and when to modify the design to achieve residential

FCC compliance, or to improve the robustness of the design. 

Michael Kellett wrote:

I do mean the Zedboard and I don't think that $395 is too bad...

Thank you for the quick reply.  US$395 may be good or bad, depending on what's on the board.  However, I agree with Morgaine that $395 will cut a lot of individual developers (which includes but is not limited to hobbyists) out of the running, something that is not in Zynq's interest.  I was hoping for something more like $89 for Avnet's Spartan-6 LX9 MicroBoard, but would have settled for $149 like the BeagleBoard.  US$149 is kind of a magic number for individual developers, as many find it an amount they can spend without Spousal Approval.  Given that Zynq likes to tout its "starting price below $15" [Xcell Journal 2Q2011], $395 for a community board to be supported by zedboard.org surprised me.

... but if you are going to play with the Zynq you are looking at 1000 hours plus investment so the cost of the board is not such a big issue.

Yikes.  That's 1/2 of a full-time year.  If that's true, fuggeddabouddit -- as they say in the Bronx.  In my own case, I'm familiar with cross-compiling ARM for the Cortex-A8 BeagleBoard, have lots of experience with Verilog-based design for Spartan-IIE and -3A, and lots of general embedded device-level programming experience.  I had assumed that the Xilinx ISE that supports the Zynq FPGA would be pretty much the same as ISE 12.2 (what I'm using now for Spartan-3A) and the ARM processor would be pretty much compatible with the CodeSourcery GCC tools I'm using now for BeagleBoard.  If Xilinx has decided to throw a bunch of new tools in place to keep me as far away from their silicon as possible, the result will most likely be that they'll succeed in keeping me far away from their silicon.

The state of maturity of the Zynq and its support stuff suggests to me that Xilinx are not ready for hobby (is there a better word ?) support.

I would suggest the phrase "not ready for a large number of developers".  Your comment reminds me way too much of Xilinx's Virtex-II Pro family which incorporated both FPGA logic and IBM PowerPC core(s).  I've heard Virtex-II Pro was not very successful.  We considered it at one time until we saw the pricing, which IIRC was at least US$100 per chip.  So we were much better off with a $10 embedded PowerPC plus a $16 Spartan-IIE, communicating using PCI.  I heard the Virtex-II Pro tools had a lot of challenges, and that you had to successfully configure the FPGA before you could talk to the PowerPC, so you couldn't use the PowerPC to help debug the FPGA.  I think this has been fixed in the Zynq, i.e., you can boot the ARM processor which can then load the FPGA logic.

When the Zynq has been around for a while I expect much cheaper boards to appear -- right now AFAIK you won't be able to buy chips through the usual channels until December.

I guess I'll wait then -- and also find out if Zynq is worth waiting for.

Ah well, it's academic anyway.  Although we enjoy playing with sexy new chips, I would never recommend heading down a road that belongs to a single vendor, on principle.

@Morgaine

Very nearly all processor or SOC chips are single sourced these days  - you can try to pick generally applicable development tools like C or VHDL but when you hit the chip itself even if its a widely used core liek ARM then all the peripherals on chip will be proprietory. So using a Zynq leves me n worse off than using a Lattice FPGA and an STM32Fxxx.

@John

The reason I think the Zynq requires a big investment in time is to get something useful out of it - its a dual core ARM with a very tightly integrated chunk of FPGA and some nice peripheral parts like dual Gbit Ethernet MACs. Where it scores (massively) over FPGA + Processor is that the FPGA can couple directly into the cache control/snoop system for the dual core ARMs so you can transfer data rapidly between fabric and processors or peripherals. I think you can shove data out of the FPGA into the cache and out onto Ethernet by DMA without bothering the processor (apart for it setting things up). Past experience with doing the same thing with separate chips (AVR32 and Lattice FPGA) says it will take a lot of work ! My guess is that any application that really uses a good chunk of the chip will take a while to get to grips with.

My suspicion is that without some serious investment in tools it will be difficult to work with  - a fast simulator for the FPGA side and multi core debugging for the ARM side. I doubt that free tools are up to the job.

Michael Kellett

@Michael:  There are degrees of "proprietariness", if that's a word.  A Zynq is a lot worse along that dimension than a common ARM device with CMSIS-compliant SPI talking to a standard bit of VHDL or Verilog.  Xilinx's newfangled stuff probably has many benefits over the more generic approach, but one benefit it won't have is low vendor lock-in.

I know you're right that there's lock-in everywhere, but it's a matter of degree, and I'm becoming less and less interested in vendors who do their damnest to be as distant from inter-vendor portability as possible.

It's an issue that is heavily affected by one's worldview.  Mine makes me averse to becoming dependent on a faceless corp that couldn't care less about people who aren't significant customers.

Morgaine.

Morgaine Dinova wrote:

 

There are degrees of "proprietariness", if that's a word.

I would recommend the word "secrecy".  From what I've heard and read, there are two principal reasons for this secrecy: fear and greed.  A certain amount of fear is justified.  I have read that vendors are reluctant to publish technical details because it makes it easier competitors and patent trolls to file frivolous patent infringement lawsuits, particularly in the USA.  It's extremely expensive and distracting to defend against those suits in the USA, even when the suits are entirely bogus.  It's very rare for USA courts to award the defendant costs if the defendant wins, which would otherwise discourage plaintiffs from filing frivolous cases.  Keeping the technology locked behind a wall of secrecy helps keep lawsuits away.

Another fear is that if you publish technical details it will be too easy for competitors to produce a functional clone of your design -- or an direct infringing copy.  So as a company you need to balance the fear of lawsuits and theft against the benefits of having an open architecture.  Intel chose to make their instruction set open, and have had overwhelming success.  FPGA vendors have chosen to make their internal architectures closed, and they remain niche players in spite of vastly superior performance over general-purpose CPUs.  Fear can make individuals act contrary to their best interests.  The same is true of corporations.  Therapy can help, but first you have to recognize that you have a problem.

Greed is another important factor, specifically the vendor lock-in Morgaine mentions.  Some companies just want to trap as many prospects as possible, and keep them as customers by walling them in.  However, that same wall keeps many prospects out.  Since it's hard to count the number of fish that got away, the lock-in advocates have an advantage when setting company policy.  (I have many wonderful little development boards that each have proprietary USB interfaces which require me to use the vendor's software and agree to the vendor's EULA to use their little board.  Some, like the ST Discovery, make it easy for me to substitute my own JTAG interface, but it sure would make me a lot happier if they'd simply open up the USB software interface so I could use whatever tools I want.)

A lot of secrecy is just corporate culture: some companies are good community stewards while others just want to grab as much profit as legally possible.  I admire Google's official corporate policy of "Do No Evil", which protects them from potential lawsuits by shareholdes who might accuse Google of not using its position to make more money.  Google can tell them that they should have considered the "Do No Evil" policy when choosing to invest in Google, and if they believe companies should do everything they can get away with to make money then the investors should choose other investments.

John Beetem wrote:

 

I have read that vendors are reluctant to publish technical details because it makes it easier competitors and patent trolls to file frivolous patent infringement lawsuits, particularly in the USA.  It's extremely expensive and distracting to defend against those suits in the USA, even when the suits are entirely bogus.  It's very rare for USA courts to award the defendant costs if the defendant wins, which would otherwise discourage plaintiffs from filing frivolous cases.  Keeping the technology locked behind a wall of secrecy helps keep lawsuits away.

I would have sympathy with US corps that claim that as the reason for secrecy, if they didn't themselves make the situation worse by buying into the patent game and refusing to call for an end to it.  Alas, it's not happening.  They all know that the situation is a disaster for everybody including themselves, and they have the collective power to buy more appropriate legislation (which is how it works in the US), yet they refuse to get together and do something about it.  No sympathy.

FPGA vendors have chosen to make their internal architectures closed, and they remain niche players in spite of vastly superior performance over general-purpose CPUs.  Fear can make individuals act contrary to their best interests.  The same is true of corporations.  Therapy can help, but first you have to recognize that you have a problem.

Haha, love that paragraph.

Some companies just want to trap as many prospects as possible, and keep them as customers by walling them in.  However, that same wall keeps many prospects out.  Since it's hard to count the number of fish that got away, the lock-in advocates have an advantage when setting company policy.

+5 Insightful !

A lot of secrecy is just corporate culture

I'm pretty sure that that is the primary issue in the vast majority of companies who haven't embraced openness (ie. nearly all of them).  I've been having a rather comic exchange with a Foundation member over in the RPF forums recently about opening up the SoC APIs, and it's blatantly obvious that the real problem is just corporate culture and not anything of substance, because the excuses are so shallow verging on lame.  Unfortunately, there is nothing we can do about that.  Logic and reason doesn't work.

Morgaine.

Michael Kellett wrote:

The reason I think the Zynq requires a big investment in time is to get something useful out of it - its a dual core ARM with a very tightly integrated chunk of FPGA and some nice peripheral parts like dual Gbit Ethernet MACs.

I guess my answer to that is "throw me into that briar patch!"  [Refers to Uncle Remus story about Br'er Rabbit and the Tar Baby]

Where it scores (massively) over FPGA + Processor is that the FPGA can couple directly into the cache control/snoop system for the dual core ARMs so you can transfer data rapidly between fabric and processors or peripherals. I think you can shove data out of the FPGA into the cache and out onto Ethernet by DMA without bothering the processor (apart for it setting things up). Past experience with doing the same thing with separate chips (AVR32 and Lattice FPGA) says it will take a lot of work!

Sounds a whole lot easier than designing a PCI Master/Slave interface and getting the pipelining right!

My suspicion is that without some serious investment in tools it will be difficult to work with  - a fast simulator for the FPGA side and multi core debugging for the ARM side. I doubt that free tools are up to the job.

I simulated my first FPGA design.  I was disgusted to discover that simulation hadn't improved a bit since my graduate student days.  I also discovered that the simulation didn't catch an important bug.  Since then, I've instead used evaluation boards or -- better yet -- used the current generation of a product to prototype the FPGA for the product's next generation.  Writing a decent set of simulation vectors for a design can take longer than doing the design itself.  Simulation is a necessary tool for ASICs or write-once FPGAs.  With SRAM or Flash-based FPGAs, you have other choices.  JMO/YMMV

Multi-core requires very careful, very clean design, or else IMO you'll never have a reliable product.  I don't know how much good a general-purpose debugging tool will be when you get into asynchronous interactions between multiple cores.  Fortunately, with an integrated FPGA you can design logic to help you see when asynchronous hazards actually occur.

John Beetem wrote:

 

Multi-core requires very careful, very clean design, or else IMO you'll never have a reliable product.  I don't know how much good a general-purpose debugging tool will be when you get into asynchronous interactions between multiple cores.

Indeed.  I did my research in quantifying asynchronous interactions between processes in a hard multiprocessor.  Don't get me started.

Executive summary:  1. Here Be Dragons.  2. The world of parallel computing is still in nappies.

Morgaine.

An error occurred while processing your request.

 

Reference #97.e6d27a5c.1338329860.161db

I had to laugh when I saw this webserver response just now, it's almost on-topic.

An error occurred while processing your request.

 

Reference #97.e6d27a5c.1338329860.161db

I had to laugh when I saw this webserver response just now, it's almost on-topic.

@John,

This is way off topic but so what !

Which simulator did you use. I use a paid for (ie not the version that you get free from Lattice) Aldec HDL simulator and for FPGA work if you made me choose I would swap it for the scope and logic analyser (I would rather not choose !!!!).

I don't think I would ever have got a reasonably complex FPGA design working without simulation - I agree that writing what FPGA people like to call a testbench is tedious but it's pretty much essential. Today's job is writing one for a data acquisition system: 2 x 8 channel ADCs feed into the FPGA with 8 serial data chains, data is processed (200MMACs/s), buffered in SDRAM which is accessed in page size bursts, assembled into UDP fragments and presented to the memory bus of an AVR32 which DMAs the data to Ethernet. Things like this never just work  - currently the synthesiser optimises away about half of it (due no doubt to a bug somewhere which means that the data from one of the ADCs is being blocked).

When I first used FPGAs (Xilinx device with 64 or 100 LUTs) they had a simulator caled SILOS and it was a bit grim - Aldec is quite nice.

@Morgaine

We were planning to use only one processor on the Zynq at first !

Michael Kellett

Michael Kellett wrote:

@John, which simulator did you use?

It was the version of ModelSim that came with the Xilinx package.  Aldec HDL may be substantially better.

I don't think I would ever have got a reasonably complex FPGA design working without simulation - I agree that writing what FPGA people like to call a testbench is tedious but it's pretty much essential.

IMO, the best way to use a simulator for FPGAs is to have someone else write the test-bench, working from the design spec and not knowing anything about the detailed logic.  If I write a simulation test-bench for my own design, I'd do a terrible job because my heart wouldn't be in it and I'd leave out important tests by assuming things should work that should really be tested.  Anyway, this is my excuse to avoid an unpleasant task :-)

Also, my philosophy is to treat FPGA logic more like software than hardware.  I think of the synthesizer, place, and route as an optimizing compiler which generates real-time machine language.  I think of a simulator as an interpreter which provides better diagnostics than the bare metal, but may behave differently in subtle ways because it's really hard to ensure that the logic simulated is exactly the same as the logic synthesized.  When I write in C, I run the executable on the bare metal, not on a simulator or in an interpreter.  So I'm happy to do the same thing with FPGA logic.

The system that uses my FPGA logic is quite complex, so simulating it in a test bench is daunting.  I should also mention that I have full control over the software that tests my FPGA: it's not like I must get test software from a separate software group which hates and mistrusts hardware people.  I've worked in such environments in the past and it's not fun.

Things like this never just work  - currently the synthesiser optimises away about half of it (due no doubt to a bug somewhere which means that the data from one of the ADCs is being blocked).

One of the things that really annoys me about Xilinx FPGA software is that I've never found a way to produce a nice, easy-to-read netlist to tell me what logic the synthesizer and mapper actually produced.  I had this for Xilinx CPLDs, and found it an important debugging tool.  Sure, the tools will happily generate a schematic for me but those are IMO pretty useless once a design gets past a few dozen gates.

The synthesizer is probably giving you a warning about the logic it optimized away.  It's probably also giving you 250 other warnings, so finding the one you need among the false alarms is impractical.  What I do is filter the Xilinx synthesizer report using a sed script to pull out the warnings.  Then I diff the warnings produced by a previous synthesis to the latest synthesis.  That has turned out to be extremely useful to see if a design change has surprises.