I've been thinking of using a generate for the I/O ports on the Xilinx targets, or at least a concatenation. On other targets this is not always possible because the Propeller pins are not on adjacent physical pins or whatever.
You lost me a little with your proposal to add regs at the I/O level, I'm not sure what you want to accomplish but I have two Propeller projects where cogs communicate via pins, and a 0-cycle delay is essential.
I'll merge the Xilinx branch to the Rel branch, then I'll work on modifying the DE0-Nano and DE2-115 targets to use the architecture where there's a target-specific top module that uses p1v.v to implement the Propeller.
The generate can be done to just index the pin[] and other registers one index at a time in a for loop, the resulting code is identical to what's already there, with no need for the 'define either. Should work on any FPGA as long as the individual pins are defined by a physical constraint elsewhere, outside of the Verilog.
So the story with the synchronizers is this: All flops are susceptible to metastability, i.e. latchup, if the setup time of the input is violated. All of the prop inputs are asynchronous to any clock in the design, so you have no guarantees that input signals will not be at just the wrong voltage level when the first flop goes to latch the input to cause this problem. The standard FPGA solution to bringing async signals into a synchronous domain is to pass them through multiple flops clocked in the destination domain, each one reduces the risk and increases the MTBF, at the cost of latency.
So technically, to improve the reliability of the prop emulation, the inputs should be synced in this fashion. However, then we will have increased the latency before a different cog will see the output produced by another cog on a given pin. As far as I can tell there is no internal shortcut already in the design to deal with this, so as things stand the output signal is already going all the way to the pad IOBUF and then looping back through the input path, but I think the timer is ignoring that path and there's no guarantee that you're seeing those outputs loop all the way back in a single clock cycle right now. It may still "work" with an extra cycle or so, but if you're relying on the instantaneous feedback down to a single clock cycle I think that may not actually be happening right now anyway. I still need to dig further.
So technically, to improve the reliability of the prop emulation, the inputs should be synced in this fashion. However, then we increase the latency before a different cog will see the output produced by another cog on a given pin. As far as I can tell there is no internal shortcut already in the design to deal with this, so as things stand the output signal is already going all the way to the pad IOBUF and then looping back through the input path, but I think the timer is ignoring that path and there's no guarantee that you're seeing those outputs loop all the way back in a single clock cycle right now. It may still "work" with an extra cycle or so, but if you're relying on the instantaneous feedback down to a single clock cycle I think that may not actually be happening right now anyway. I still need to dig further.
I recall seeing something about the real P1 not quite coping, along the lines of when a Timer out in single-impulse out mode, is used to feed another timer.
Not all pins 'work the same', and the issue looks to be that the Tplh, Tphl are different, and the pulse is only one clock wide, so some skews can 'shrink' to inside the sample points, and be missed (but only just missed).
Better could be to sample on the other edge, than updates the pins ?
I'm trying to avoid messing with anything inside the cogs themselves for fear of having some unintentional side effect on compatibility. If we were to implement the input synchronizers (at the top) for input reliability, I'd still sample them synchronously with the rising edge of the 80Mhz clock to give them the maximum amount of time to set up for the next clock cycle, and use constraints to ensure that place & route tries to conform to the desired timing. Sampling the output signals on the falling edge would only help if there was uncertainty about the timing, which there doesn't need to be in the FPGA, and it would still cut the available setup time in half for the next flop. Unfortunately, as currently designed we seem to be on the edge of having difficulties meeting timing, since the lowest speed grade chips are used in the student/hobbyist boards, and the Prop IO architecture is complex with all the different sources of outputs and the wired-ORing of everything creating additional layers of LUTs, and the high fanout of all the inputs to multiple places in each cog.
This thread comes very timely As i got this toy last week:
I've got the version with the same 35t FPGA variant as available on the Arty.
Have started converting the Arty codebase, but this is my 1st time using Vivado (have only used Quartus before). When I have got something working I'll come back.
This is what I would like to achieve:
since the RTS is not broken out on the cmodA7 I don't think we can use the onboard FTDI as a propplug replacement.
Need to decide how to handle RESn (for now put on a GPIO pin, but thinking of a little HW modification that let's me use one of the buttons as a Reset button with an extra pin connected to it)
The CMod looks like an interesting part. Both variants should be big enough for a P1V.
The clock input is different so you'll have to change the clock generator to work with 12MHz instead of 100MHz. That should be easy to do.
You're right, without the RTS or DTR pin from the FTDI wired up to the FPGA, you'll have to use a Prop plug. I suppose the PMOD header would be a good place because it has GND right next to a couple of pins that are connected to the FPGA.(*)
Programming one of the buttons as reset button is a matter of adding a few lines of Verilog at the top level; no hardware modifications needed
I don't have the hardware to test it, but @rosco_pc if you want to provide source files for these, I'd be happy to integrate them. Please clone my Github repo at https://github.com/JacGoudsmit/P1V, create a new branch and generate a pull-request of your changes. Thanks in advance!
By the way, it's easy to find EEPROM modules that are compatible with PMOD headers on the Nexys, Arty, CMod and other Digilent boards. Google for "EEPROM module" and click on the Shopping link. Make sure you get a module that has a 24LC256 or 24LC512 and that it has VCC on the corner, GND next to it, and SDA/SCL (in any order) next to GND.
For example there's this one for about 3 dollars including shipping, including wires. If you change the Verilog code to connect Propeller pin 28 to SCL and 29 to SDA on the PMOD header, you can plug the EEPROM right into the PMOD header without those wires.
If anyone is interested, I can write the change into the Arty code. Let me know.
My DE0-Nano died a month or so ago, ( I likely killed it but received my Arty board last week. I am waiting on a couple of PMOD boards ( SDcard and Flash ROM ). from Trendz in Germany.
There were a couple of non critical warnings during compile but Arty-P1V is up and running and looks ok at this stage.
Comments
You lost me a little with your proposal to add regs at the I/O level, I'm not sure what you want to accomplish but I have two Propeller projects where cogs communicate via pins, and a 0-cycle delay is essential.
I'll merge the Xilinx branch to the Rel branch, then I'll work on modifying the DE0-Nano and DE2-115 targets to use the architecture where there's a target-specific top module that uses p1v.v to implement the Propeller.
=== Jac
So the story with the synchronizers is this: All flops are susceptible to metastability, i.e. latchup, if the setup time of the input is violated. All of the prop inputs are asynchronous to any clock in the design, so you have no guarantees that input signals will not be at just the wrong voltage level when the first flop goes to latch the input to cause this problem. The standard FPGA solution to bringing async signals into a synchronous domain is to pass them through multiple flops clocked in the destination domain, each one reduces the risk and increases the MTBF, at the cost of latency.
So technically, to improve the reliability of the prop emulation, the inputs should be synced in this fashion. However, then we will have increased the latency before a different cog will see the output produced by another cog on a given pin. As far as I can tell there is no internal shortcut already in the design to deal with this, so as things stand the output signal is already going all the way to the pad IOBUF and then looping back through the input path, but I think the timer is ignoring that path and there's no guarantee that you're seeing those outputs loop all the way back in a single clock cycle right now. It may still "work" with an extra cycle or so, but if you're relying on the instantaneous feedback down to a single clock cycle I think that may not actually be happening right now anyway. I still need to dig further.
I recall seeing something about the real P1 not quite coping, along the lines of when a Timer out in single-impulse out mode, is used to feed another timer.
Not all pins 'work the same', and the issue looks to be that the Tplh, Tphl are different, and the pulse is only one clock wide, so some skews can 'shrink' to inside the sample points, and be missed (but only just missed).
Better could be to sample on the other edge, than updates the pins ?
I've got the version with the same 35t FPGA variant as available on the Arty.
Have started converting the Arty codebase, but this is my 1st time using Vivado (have only used Quartus before). When I have got something working I'll come back.
This is what I would like to achieve:
since the RTS is not broken out on the cmodA7 I don't think we can use the onboard FTDI as a propplug replacement.
Need to decide how to handle RESn (for now put on a GPIO pin, but thinking of a little HW modification that let's me use one of the buttons as a Reset button with an extra pin connected to it)
Your images are too small to read.
dgately
The clock input is different so you'll have to change the clock generator to work with 12MHz instead of 100MHz. That should be easy to do.
You're right, without the RTS or DTR pin from the FTDI wired up to the FPGA, you'll have to use a Prop plug. I suppose the PMOD header would be a good place because it has GND right next to a couple of pins that are connected to the FPGA.(*)
Programming one of the buttons as reset button is a matter of adding a few lines of Verilog at the top level; no hardware modifications needed
I don't have the hardware to test it, but @rosco_pc if you want to provide source files for these, I'd be happy to integrate them. Please clone my Github repo at https://github.com/JacGoudsmit/P1V, create a new branch and generate a pull-request of your changes. Thanks in advance!
===Jac
PS Let's start a new thread for this.
For example there's this one for about 3 dollars including shipping, including wires. If you change the Verilog code to connect Propeller pin 28 to SCL and 29 to SDA on the PMOD header, you can plug the EEPROM right into the PMOD header without those wires.
If anyone is interested, I can write the change into the Arty code. Let me know.
===Jac
My DE0-Nano died a month or so ago, ( I likely killed it
There were a couple of non critical warnings during compile but Arty-P1V is up and running and looks ok at this stage.
Ron