No, what they have done is put a bomb under the Open Source Hardware movement. Exposing it for the sham it is.

As the AdaFruit guys pointed out, Open Source Hardware is a myth. Sure, like the Arduino and such the schematics of the board are open, and even the board design files are open. But it uses an AVR micro-controller that is anything but open source. Any monkey can put that AVR on a PCB, you don't even need the PCB to use those AVRs.

BUT, with the release of the P1 design files we witness the first time in history that is possible to even actually have an open source hardware design based on a processor in current production.

Everything from the application software, to the processor it runs on, to the board schematic and layout can now be truly open.

You can really take that total design and get it made, by Altera or Xylinx or as an ASIC or whatever you like.

Can/would someone compare the Altera Cyclone V 5CEBA2xxxC8N F484 with the Xilinx Spartan 6 XC6SLX25-2xxxxxxC for use as a P1 development ???

Both have BGA 256 and 484 pin versions and about 25K LUTs.
Distributed RAM seems similar at about 220KB
Block RAM needs further investigation - Altera quote 196 and Xilinx 52 but I think they are different bases - I need to look deeper.
Both support SDRAM.

Does anyone know about the FPGA software from both Altera and Xilinx - Are these chips supported with the free downloadable versions?

add a new CALL/JMP/RET instruction (using one of the 4 free instructions)

to include a 16-18 bit immediate absolute goto address

add PortB - ie 64 I/O

make 48KB hub ram with the top 16KB double mapped

But before I start I am going to download Quartus on my wife's faster laptop. Have to do the download at my son's since I have limited download data (mobile only).
So nothing is going to happen here for a few days at least.

Does anyone know about the FPGA software from both Altera and Xilinx - Are these chips supported with the free downloadable versions?

I am no guru, but I have been frantically reading all.day.long on what is available. From what I read the free Web version for the Altera supports all the V series except the top of the line -9 version.

add a new CALL/JMP/RET instruction (using one of the 4 free instructions)

to include a 16-18 bit immediate absolute goto address

add PortB - ie 64 I/O

make 48KB hub ram with the top 16KB double mapped

But before I start I am going to download Quartus on my wife's faster laptop. Have to do the download at my son's since I have limited download data (mobile only).
So nothing is going to happen here for a few days at least.

Again, we need a way to load 32 bit constants. That could be in the form of:

mov r1, #my_constant
rdlong r0, r1
...
my_constant long $12345678

However, that approach takes three longs, two for instructions and one for the constant itself where the AUGS solution takes only two longs.

Everything from the application software, to the processor it runs on, to the board schematic and layout can now be truly open.

Actually, no.
The FPGA tools are certainly NOT open, and the FPGAs themselves are NOT open, and most of the FPGA boards are NOT open.
All you have done, is move some hardware, into software. Open Source Hardware is still a myth.

However, semantics aside, this does have great educational and niche use potential.

Actually, no.
The FPGA tools are certainly NOT open, and the FPGAs themselves are NOT open, and most of the FPGA boards are NOT open.
All you have done, is move some hardware, into software. Open Source Hardware is still a myth.

However, semantics aside, this does have great educational and niche use potential.

I take a different view. The Propeller is open source, so any programs I write to run on it can be open source from top to bottom. If I want to make a derivative Propeller then it's no longer fully open source (since, as you pointed out, it runs on a closed source FPGA). But my Propeller chips themselves are now open.

Again, we need a way to load 32 bit constants. That could be in the form of:

mov r1, #my_constant
rdlong r0, r1
...
my_constant long $12345678

However, that approach takes three longs, two for instructions and one for the constant itself where the AUGS solution takes only two longs.

David,
Could we get by with a 16 bit constant (for 64KB hub) which could be expanded to an 18bit constant for 256KB hub?
Why? Well we have 4 unused P1 instructions plus the ability to expand the SYSOP instruction while totally keeping backward compatibility.
So, one will be the CALL/JMP/RET with 16-18 bit constant (absolute address) - I am thinking just using the D&S bits gives us 18 bits. Using KISS means that the lowest 2 bits will always be 00.

BTW The way Chip has coded the P1, he keeps the instruction set completely regular. So you have to be careful if we try to use the zcri or cccc bits for anything other purpose.

So, CALL/JMP/RET will use a fixed register $1EF (or later maybe $1EC-1EF by using the lower 2 bits of S).
BTW this is already complex enough because we have to add wait states for the hub access, and this is going to cause possible delays in the completion of the previous instructions writeback.

Everything from the application software, to the processor it runs on, to the board schematic and layout can now be truly open.

Actually, no.
The FPGA tools are certainly NOT open, and the FPGAs themselves are NOT open, and most of the FPGA boards are NOT open.
All you have done, is move some hardware, into software. Open Source Hardware is still a myth.

However, semantics aside, this does have great educational and niche use potential.

With these semantics, even Linux is not open sourced because it only runs on closed sourced chips.
So, the only truly open sourced chip is the propeller chip. Anything else on the pcb is proprietary. That means the regulator, the eeprom (or the chip involved in downloading and the device which did the downloading), and even the capacitors on the boards.
And stretching this even further, the factories that make chips are closed source - you cannot make the chips yourself.

David: At least making the transistors yourself is possible. But I don't think I would like to be doing that many

Let's get past the myth, and just appreciate what Parallax has done, and get back on topic please

Actually, no.
The FPGA tools are certainly NOT open, and the FPGAs themselves are NOT open, and most of the FPGA boards are NOT open. All you have done, is move some hardware, into software. Open Source Hardware is still a myth.

Actually yes.

When I publish my C code it is open source. No matter if there exists an open source C compiler to make it into executables or not. You are free to do with it what you like. Compile it how you like. Run it on whatever machine you like.

In the worst case you would have to translate my C into assembler manually, you know, with a pencil and paper. Perhaps you would then have to translate that assembler into HEX or binary manually. Then you have a program you can load into your machine and run. A machine, by the way, that I may never have heard of when I wrote my C code.

Similarly that Verilog is a description of a machine, a Propeller MCU. It is not dependant on Altera or FPGAs at all. You could use Xylinx tools and devices. You could get your own ASIC or whatever silicon made. With a bit of sweat you could manually translate that Verilog into a circuit diagram, using pencil and paper, for a circuit built out of 74 series logic chips or discrete transistors or even vacuum tubes!

The fact that the platform presented to implement that Verilog on is a closed FPGA from Altera does not detract from the openness of the Verilog.

With these semantics, even Linux is not open sourced because it only runs on closed sourced chips.

Except that is not true. Linux runs on OpenRISC an open source processor design you will find on opencores.org.

You are right about the semantics.

My source code can be open source even if there is no compiler yet written that can compile it or no hardware that can run it.
If you think that is crazy remember Ada Lovelace was writing code for a machine Babbage never managed to build!

The point about being open is that he user can see it, change it, rearrange it, share it. The details of how it might actually get built is irrelevant and is up to the user.

David,
Could we get by with a 16 bit constant (for 64KB hub) which could be expanded to an 18bit constant for 256KB hub?
Why? Well we have 4 unused P1 instructions plus the ability to expand the SYSOP instruction while totally keeping backward compatibility.
So, one will be the CALL/JMP/RET with 16-18 bit constant (absolute address) - I am thinking just using the D&S bits gives us 18 bits. Using KISS means that the lowest 2 bits will always be 00.

BTW The way Chip has coded the P1, he keeps the instruction set completely regular. So you have to be careful if we try to use the zcri or cccc bits for anything other purpose.

So, CALL/JMP/RET will use a fixed register $1EF (or later maybe $1EC-1EF by using the lower 2 bits of S).
BTW this is already complex enough because we have to add wait states for the hub access, and this is going to cause possible delays in the completion of the previous instructions writeback.

The second one is much more difficult as there is wait states to take care of.

One needs to be some form of load address, so maybe the same as the CALL format using D&S for 16-18 bits.

RDLONGX would generate denser code since it wouldn't need to be followed by a RDLONG. It's too bad it would have to load to a fixed address though. What about a limited version of AUGS that just added 9 bits to the existing 9 bits in the S field of the next instruction? Then you could load any register?

When I publish my C code it is open source. No matter if there exists an open source C compiler to make it into executables or not. You are free to do with it what you like. Compile it how you like. Run it on whatever machine you like.

Agreed, But you were talking about open source hardware. not software.

The fact that the platform presented to implement that Verilog on is a closed FPGA from Altera does not detract from the openness of the Verilog.

We actually agree.

The Software source code is open source, the hardware (and the software needed to RUN that HW) is not.
So best limit the discussions to "the openness of the Verilog." and not try to claim open source hardware pathways..

RDLONGX would generate denser code since it wouldn't need to be followed by a RDLONG. It's too bad it would have to load to a fixed address though. What about a limited version of AUGS that just added 9 bits to the existing 9 bits in the S field of the next instruction? Then you could load any register?

The way its currently coded, this is a lot of work for me. At least for now, I want to keep any changes very simple.
I think the load will be the simplest to start off with, rather than call/jmp/ret.

Interesting results from Chip["It turns out that even though this Cyclone V -A2 part has 25k LE's, the P8X32A takes 85% of them! That's 33% more LE's than it takes on the Cyclone IV. Plus, it took 3x longer to compile. Oh, and Fmax is still over 80MHz, but slower than Cyclone IV. Only good thing is, these Cyclone V FPGA's cost half what the Cyclone IV devices cost in similar (higher) densities."]

The way its currently coded, this is a lot of work for me. At least for now, I want to keep any changes very simple.
I think the load will be the simplest to start off with, rather than call/jmp/ret.

ozpropdev, added.

I suppose it isn't such a big deal that the constant always gets loaded into the same location since the LOAD# instruction will likely always be followed by a RDxxxx, WRxxxx, JMP, or CALL indirect through that location.

Since they sell it in numbers departing from two units, it can be a good chance for a group buy!
Sad I'm in Brazil, but my youngest daughter lives in Sidney! Perhaps she wants to find a good gift for a distant living daddy!