[email protected] wrote:
First, it's great that we are starting to get an open parallel
GPU software stack. This can all get leveraged by open hardware.
Heck yeah. I assume that Jeff Bush character would like to see this as
well :)
But Try doing secure boot (or just working with a bootloader)
on an Intel CPU and you might see why it's a non-starter.
I don't mess with secure boot. I've run some fairly recent stuff and
have seen the bios options, but have not had a hiccup yet. If I did,
that product is going back into the box and being returned, and the
vendors have to know this.
The problem with 'disposable' consumer hardware is... it's
disposable.
This is also the benefit. When I build around some consumer tech, If it
is important I'll buy several extra to stick on the shelf. Yes, it's
going to die, but even the high end industrial controls die after 20+
years in the field. Normally I find these obsolete controls are not
worth dealing with, and yes impossible or terribly expensive to get
parts for. Even after you do fix them, something else dies soon after.
That's just entropy, man.
Re: Relay logic. It fails more frequently than a normal PLC and you may
need the higher tech (faster) stuff to remain competitive. Most times
it got retrofit when it became too problematic. I've had to fix this
stuff on occasion (without a schematic), and it is not fun.
I cannot afford the testing to re-qualify a new disposable
hardware platform if I'm in the middle of harvest. I have
to find a replacement part and get the combine moving again
as fast as possible. For this reason, if I don't have the
silicon mask I can call up a fab house running on 15 year
old tech and have them make me a few wafers of spares,
then it's pointless.
I might as well just save my effort, and use pre-computer
technology (relays and switches) because I can troubleshoot,
repair, and replace it when it fails.
Unless, of course, someone decides to offer long-term support
on the 'disposable' consumer hardware by opening up the masks,
then I might think it's worth my time to document all the
hardware bugs and fix the ones that irritate me.
I have not yet had the chance to muck around in a clean room, so could
be wrong, but I question your economics of getting a couple wafers baked
quickly on the sly.
Have you considered your own fpga development platform? That's exactly
what I, and it looks like whygee have done. You will have to migrate
your board from fpga family to family - but this is a once a decade
scale problem, and the RTL is yours, or pull from opencores.
Yes, the place/route tools are not nearly as open as we would like, but
the only question is will one of the several vendors have something open
'enough' in 10 years - I (have) bet the answer is yes. I think all the
big vendor's tools run under Linux. Even Microchip's development
platform is supported under Linux. This is the way the industry seems
to be moving.
You can retain an entirely tool independent core code by working with
ghdl if vhdl, or I think icarus if verilog (I don't use verilog). This
plus coding in 'c' gets you very close to the metal with a completely
open tool chain. I use Xilinx's tools by just symbolic linking
externally developed vhdl files into the project directory.
But I really don't know the systems, sensors or controls you are trying
to interface - this may be overkill.
In the meantime though, an open infiniband core for an FPGA
might be really interesting link to connect to fast disposable
stuff that can do fancy things that are nice to have but are
not critical to operation... see
http://seniord.ece.iastate.edu/may0904/project-files.html
https://bitbucket.org/tmagik/infiniband-fpga
Thanks for the links. I'll read up on it.
I picked Ethernet because it was very open, had good bandwidth, is
ubiquitous (even on the factory floor), has galvanic isolation, and is
an inexpensive standard to implement and use. I strongly dislike the
variable latency, but can live with that. (I know etherCAT is out there)
I also dislike the complexity of the TCP/IP stack, but I think it has
been easier/simpler than messing around with USB.
-John
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
