I found this attendant console in a thrift store in San Francisco for $4. It is covered with LEDs and buttons, and has a very high build quality. I thought about how hard it would be to make something similar today (with just the cost of LEDs and buttons), and decided to pick it up for a later project.
This repository is the result of my reverse engineering of the ATT26A hardware/firmware and includes:
* Documentation of the hardware.
* Documentation of the wire protocol.
* Python library for driving the panel.
* Example programs for using the python library.
These Attendant Consoles can be found on ebay for around $25 (at the time of writing). If you are into unusual display interfaces, pick one up and see what you can do.
New examples, patches, and new language bindings welcome.
I disagree that it is trivial. If we know what bits of the unencrypted bitstream do what, and have a cryptographically secure way of signing the stream, then GLHF with that. If it turns out that documenting the parts of the chip required for configuration makes the black box security not work, then it was crap security and provided no real security to anyone. As it stands there is no way to tell and we have to take the smiling sales guy's word that it is "SUPER secure, promise".
This is an interesting story. An unfortunate end.
Most of these things sound like short term issues that get resolved as the tools are made. Alternately Xilinx could have just put the docs out there and said they only support ISE. That way if an open source developer makes a tool they have no responsibility, but can reconsider in a few years in case it gets wide acceptance.
I am not a market strategist, but supporting everyone's custom tool sounds like a quick way to waste money and the wrong way to try and open source something. Similar to respecting every coupon people bring in, even hand written ones.
'get to the level' of ISE... I disagree. I do not want to build an IDE. I want an open toolchain, the thing that the ISE interface calls. There is some math in there that takes certain skills to implement, but I know several people who could do it if they had the layout of the chips.
MAYBE the reason there are no open toolchains 'on the level' of ISE and competitors is not because Xilinx has some amazing secret sauce and is instead because the whole industry is caustically secretive and horribly anti competition.
This feels like circular logic to me. We do not want the hardware companies spending time 'open sourcing' their docs because they need to spend that time and money 'making more features' which they wouldn't have to do alone if it was open, but we can't have it open because spending the time and money 'open sourcing' their docs......
I think there is a big difference between 'users wanting tools to be closed source' and 'users not caring if their tools are closed source'. And I would argue that even if the primary user base does not care, we can do better than that. It is no excuse to use these fragile lumbering behemoths of bad design and super seeeeecret tricks that you can learn in a university or the internet. And history keeps showing the problems of big black boxes with the words 'trust us' written on the outside. All we need is the layout and a map of the bitstream and open developers will do most of the work for these companies.
As for spending their resources 'driving prices down', that is quite relative. And if you look at the pricing model of their software it is clearly not their goal to make that reasonable (at least Xilinx). And every version of the software stretches to provide arbitrary bullet points on the back of a box that either mean nothing, were tested in suspicious conditions, or conflate multiple optimized tests together and say 'we are better than everyone at everything. How many times will that be said by all competitors at the same time, and how many times will it be believed? Anyways, with all those features, somehow ISE is still unstable on windows.
When you say 'good, efficient software' i wonder if you are talking about Xilinx ISE/Vivado, or any of the tools from their competitors. I can not imagine you are.
Note that Altera's compiler for Open CL does not let you run your OpenCl stuff faster. It is intended so you can write your FPGA programs (that run outside of your computer usually) in OpenCL. Most of the imagined benefits kind of vanish, at least to me, when you realize that this is just a tool so if all you can hire if OpenCL developers, you can still get the job done.
You have to change out a certain DLL for POST windows 8 in order to get ISE to behave and not crash randomly. YAY! Xilinx said they didn't care but somewhere on their support forum there is some kind soul who said what dll to rename (they have two versions of the DLL in the install anyways but they did not use the win 8 one by default and refuse to patch).
Companies seem to be terrified of trying anything. That is why I was happy when Sony put The Interview up on the internet and theaters for simultaneous release. No one would try that first, and since it worked ok for them it is now an option other companies may consider.
Even though both GPU companies and FPGA companies are in hardware, they do not see strategic experiments like opening documentation in the other to be sign of viability for themselves.
Those jobs also pay you to sell your ideas that you are never allowed to use again unless you continue working for the company you sold it to. And if you have the gall to use your own idea, lawyers!
I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.
In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.
Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.
While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.
I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.
Amusingly the Xilinx license states that you are not allowed to use the bitstreams generated by their software in any device that they did not manufacture. This means if you implemented a xilinx fpga in an altera fpga, it would be against the agreement to program the inner xilinx fpga with the bitstream. The more you know!
I get there is a big difference between hardware and software, but I feel that certain parts of the gaps are closing. They will not CLOSE, but as they get closer we can learn from each other.
With that said, to address your point: Linux is one of the most dominant systems for servers. Google, Facebook, Twitter, etc use it for almost all of their backend systems. They use it not just because it is free but because it is proven and scalable. Open source databases and web servers also enjoy considerable (sometimes dominant) share.
There are companies that provide support contracts for Linux (Suse, Redhat) and that model has worked to fund other open software.
So I think that establishes that a company will use open software.
As for being scary, you are correct that is a primary decision making motivation. It is why many professionals in tons of industries still run windows XP. Often they NEED XP because the software they rely on is so dependent on that specific ecosystem that huge rewrites are necessary in order for it to work on anything else, and this work (even if done by the original distributor) will take years for the tools to be stable again. This is not good engineering on the part of the tool designers. The crippling fear of NEVER TOUCHING ANYTHING is something that the open software alternatives seem to be alleviating in corporate environments since the late 90s.
The lifecycles of putting a phone together is much faster than Intel designing a processor, or Xilinx designing a new FPGA. building boards in phones and laptops is a complex game of Lego and placing them around so the timing diagrams work in all expected use cases. And if the timing does not work in some cases, whatever, people get a phone a year. Hell on my Galaxy S3 Verizon said 'oh yeah that is a known issue where sometimes the GPS just does not work because of loose wires, that was fixed in the S4, I think, which is only $$$.'
You are also correct about direct support from the company. In face make Xilinx enough money and they will share their secrets with you. But I am more targeting small to medium development. If open tools become popular and stable enough to get market share in hobbyist up to medium sized companies, it will only be so many years before bigger companies hire new engineers who grew up using open tools and have no patience for tools that have to be emulated in windows XP and have 35 nested sub menus for enabling a feature.
I do not feel attacked at all. You brought up interesting points. I hope i did them justice and did not ramble since there were a lot of points to hit.
This is a severe problem that saddens me greatly. For now I am just writing tools to make JTAG/SPI/etc loading of chips Ubiquitous to the developer writing software/netlists for them.
I do not know enough about the place and route math and routines, nor have I seen enough details of real life chips to know the types of real challenges faced. But I will cross that bridge when I get there (maybe it will be someone else :)).
I personally have a huge issue letting anything fundamental I figure out be marked down as the property of a company to have and hold for 20+ years. But I understand the financial rewards and interesting problems are more than enough for many people, so I can not hold it against a student with a PHD worth of debt to need cash. Sigh.
Hopefully if a good enough extensible base exists, people will add pieces on (whatever they can get away with) over a long time. That is all I can really hope for.
OpenCL support for FPGAs is super limited and only done through vendor specific tools. The point of these tools is more to LET you write your FPGA program that runs outside of a desktop computer in OpenCL than it is to make an FPGA be able to speed up your OpenCL program running on a desktop. So it is not like 'I will pop in a new FPGA card so I can play better games.' Though that is what i want to happen in the next...... lets say 5-10 years.
Sadly it is private. It is a channel for reverse engineering silicon devices. If you are interested and you hang out in IRC channels for microcontrollers, FPGAs, etc, and ask the right questions you may get an invite.
I get the idea you are aiming for, but this will not work.
GPUs are vector processors. They are good at certain types of repetitive unrelated (parallel) math. They can be good at simulating physics since physics is described with matrix math.
You could simulate the gates in a chip, though this is a MASSIVE problem and will tax the GPU for meh results. If you decided to simulate a chip in a GPU, simulating an FPGA would be quite pointless since FPGAs are less than optimal so they can be reconfigured to implement (not simulate) different chips.
This would be like running a Sparc emulator in a Java VM implementation of an Intel VM... mabe throw javascript in there somewhere. Each level of emulation, simulation, or implementation robs resources.
Yes those architectures are more open but they do not do the same thing. More work with those setups so, say, Postgres can offload certain math to the GPU, is great and should be done. But this is somewhat different than FPGAs (though in the same spirit).
CPUs, GPUs, and FPGAs all solve different types of problems very well. But they do not run each other's problems well, and certainly do not implement each other super well. Well, with one exception: you can build a reasonable GPU with shaders in an FPGA, but this is not to out perform the FPGA it is implemented on in a task. If you hardwired the FPGA to run the equivalent operations of a shader in OpenCL running on a GPU implemented in the same FPGA, the FPGA would win hands down.
In the future if my tool for loading the chips works and is adopted, I hope to define an interface for using FPGAs directly in the computer similar to how OpenCL defines an interface for GPUs. Hopefully I would not follow the shit show that occasionally is the Chronos Group.
Some people will say that there are already pcie cards with fpgas on them and that this is not a new idea. But the issue is that existing cards like Digilent make are there for building pcie card designs. The FPGA (usually one) on the board has to implement the pcie fabric plus whatever it wants to do. Imagine if when you write an OpenGL/CL program you had to deal with all the DMA work and quirks of the underlying setup.
Instead the grid of fpgas should have standard ways to access certain mapped regions of memory through a different chip that handles the PCIe transport layer stuff. If this was available then adding FPGA support into POSTGRES would not require bypassing the HAL of your kernel or worrying about timing details of something fundamental to modern computers (and thus software engineers) like PCIe.
Obviously the FPGA is still something that is hardware specific, but who knows what could be done with that. Even if we had to Synthesize from raw HDL every time, at least loading the chips would WORK. We could start using these chips to solve problems instead of thing slike a one off project by an EE major to build a grid of FPGAs that process bitcoin. The bitcoin work was impressive but it bothers me SO MUCH that they used reconfigurable devices to build a solid card with a fixed function.
I am replying to this comment instead of the multiple people under it.
You guys are right that FPGAs are not quite ready, or maybe will never be ready to be the primary radio for a phone because of the static power consumption. You could still have one available for certain burst operations that need to be highly accelerated.
Good point about the timing attacks on crypto, but hardware crypto can be updated within an FPGA. This can be seen as a pro and a con to security.
This repository is the result of my reverse engineering of the ATT26A hardware/firmware and includes:
These Attendant Consoles can be found on ebay for around $25 (at the time of writing). If you are into unusual display interfaces, pick one up and see what you can do.
New examples, patches, and new language bindings welcome.
Happy hacking!