Shirley... there must be an FPGA utility...
rjo__
Posts: 2,114
in Propeller 1
... to identify which FPGA pin is attached to which board pin.
I have demystified pin mapping for myself... but it was something of a royal pain in the beginning... and occasionally it still is.
I'll give you an example... I've never talked about this before because I don't want the limited staff and time available to Parallax to be
one bit concerned with it. I have both the DE2-115 and Nano adapter boards from Parallax. They were built and I purchased them so that I follow along with P2 development. Then Parallax decided to give us the P1V Verilog sources. There was enough information to get the pinouts for the adapter board, but not to hook up the VGA... didn't matter to me, I used the VGA on the De2-115
I still don't want Parallax to waste there time on this... there must be a utility somewhere so that I can hook up a signal to a pin on the board and figure out which FPGA pin it attaches to.
Where is it?
I have demystified pin mapping for myself... but it was something of a royal pain in the beginning... and occasionally it still is.
I'll give you an example... I've never talked about this before because I don't want the limited staff and time available to Parallax to be
one bit concerned with it. I have both the DE2-115 and Nano adapter boards from Parallax. They were built and I purchased them so that I follow along with P2 development. Then Parallax decided to give us the P1V Verilog sources. There was enough information to get the pinouts for the adapter board, but not to hook up the VGA... didn't matter to me, I used the VGA on the De2-115
I still don't want Parallax to waste there time on this... there must be a utility somewhere so that I can hook up a signal to a pin on the board and figure out which FPGA pin it attaches to.
Where is it?
Comments
I am happy with the pin-mapping tools. The problems I had initially were of my own making. The issue is... let's say you have a board... with pins etc. all hooked up, but they haven't been fully documented. As far as I know, this is still the case with the VGA pins on Parallax's add-on boards. There was documentation to do the mapping for the headers, which was really all I needed.
I was trying to imagine that there would be a utility which would allow me to turn any board on and as long as I knew which FPGA I had I could load up a utility program and apply a voltage to a pin and then the utility would provide the identity of the FPGA pin... that info would then go into excel table or whatever a person was using for pin mapping. If it is possible... no doubt it already exists.
If it doesn't exist, then I would guess it simply isn't possible.
My question came up because I was hoping to avoid asking a lot of questions about the P123.
If it doesn't exist, then I would guess it simply isn't possible.
That's run time hardware, that needs user probing, and would be very prone to errors.
Better I think is to have scripts run on PCB netlists, that simply extract the FPGA pin & connector pin.
That is comparatively low-tech,and as reliable as the netlist.
It complicates a little when there are other components in the chain,but that is less common on FPGA breakout type designs.
After rethinking it again... third and last time:) it seems like it might not be possible to do what I described without risking damage to the board. As for netlists and scripting... I'm at least a year away from understanding that stuff:) But if anyone else has looked and has a solution, I'm all ears:)
I did look at the probe pins beneath the FPGA on the Terasic Boards... and I found continuity to a user pin on the Nano. it is probably just a ground... but it could be actually be something else. It's a little hard to believe that there is continuity all the way from the FPGA to a user pin... but I suppose it is possible. I got a headache and decided to go back over to my 123 project. Everything under the FPGA on the backside of the board that can be probe has continuity to ground.
Won't that prevent someone from using the Parallax 1-2-3 board for doing their own P1v experiments or even to use it for some totally other purpose than running a Propeller image?
Won't that prevent someone from using the Parallax 1-2-3 board for doing their own P1v experiments or even to use it for some totally other purpose than running a Propeller image?
David,
I'm pretty sure documentation is coming. Limited documentation but enough to know how things are hooked up so you can map the on-board goodies to the FPGA pins and whatever FPGA program you are wanting to run.
The announcement thread also said we'd get a copy of the loader program that runs on the onboard propeller.
It's coming, just a bit later than the boards are being delivered.
It's not that complex - netlists are simple ASCII files, and the scripts do what you could do with a pencil or magic marker.
If we look at Altium exports
http://techdocs.altium.com/display/ADOH/Netlist+Outputs
lots of choices, the simplest are wires based ones
I'll export 3 from LTSpice here and let's assume R1=FPGA and R2=Connector
WireList [00004] N001 R2 2 B Passive 10k R1 1 A Passive 10kAll 3 show R2.Pin2 wires to R1.Pin1
Wirelist looks the easiest to script
That's is just sweet. I assume you can elect "get all" somehow. That would allow you to use a scripting language to parse the pins and just look at a subset. Is the tcl scripting capable of parsing this kind of list... If not, I could do it on my Mac with Applescript.
Could you show a quick and dirty way to use tcl to make two or three pin assignments? Here is my thinking... if the pins which are exposed through the pin finder(or in some other way) can be limited to user i/0, then it should be possible to find any pin in a few steps without hurting anything. There is a name for the sorting logic, which I forget of course, but the number of steps would be log base two of the number of possible pins. I know how to do it... just can't remember what it is called.
script a verilog module... to set pins en mass to output positive signal.
First pass needs to set only half of the pins.
hook up a propeller to the FPGA board pins that interest me. This gives the FPGA board identities on the FPGA side and Propeller identity on the other side.
Leave all propeller pins in default input mode.
based upon INA... assign the propeller pins to groups... on and off.
transmit results over serial to a terminal that saves the result to two txt files named by iteration and status.
take each txt file... parse it to generate a new verilog module... compile and run again... hopefully also under scripting control.
repeat repeat repeat to include the entire branching structure.
Return after the holidays.
And of course... we could encode on the verilog side and reduce the time by a lot
Each of the boards that are supported by the P1V project, have some pin headers that are currently "hard assigned" by the .QSF files in the project. For example, on the BeMicroCV (no A9) there is a small I2C EEPROM that I replaced with a 32K EEPROM, and I had to modify my .QSF file to use it. Altera provides .QSF files that already have the assignments in them but they use the pin names as they are documented in the reference manual. For example they might be called "GPIO[0:7]" and "USER_LED[1:8]" or something. In the .QSF files from Parallax, the pins were simply renamed to have names like io[0:31] so they connect with the P1V source code.
In Quartus, you can assign a different top level entity to each Revision. At this point in time, there are 3 revisions in the main branch of my P1V Github repo: one for the DE0-Nano, one for the DE2-115 and one for the BeMicroCV. What I want to do is create a new top level entity for each board (or at least each board that I own and am able to test), let's call it "top-boardname" or something. That module will specify how the FPGA-specific and board-specific pins are mapped to the P1V.
The wiring module will make it possible to change a Verilog file to assign Propeller I/O pins to different headers and different physical pins, and will make it possible (if you happen to own multiple targets) to keep track of separate pinouts for separate projects, e.g. by using `define and `ifdef.
But I want to go one step further: I want to start using the DIP switches to switch pinouts. All the currently supported P1V target boards have at least 3 dip switches (the DE2-115 has no DIP switches but it has plenty of regular switches that can be used), which makes it possible to select 8 different configurations without the need to reflash the FPGA! You want to connect the SD card reader to the P1V? Want to use the on-board EEPROM? Connect the VGA output on the DE2-115? The Ethernet PHY on the BeMicroCV-A9? Just a matter of setting the DIP switches to select which P1V I/O signals are connected to which physical pins.
Having the extra abstraction level also helps to work around problems like for example the fact that on the BeMicroCV and BeMicroCV-A9, the cog LEDs are on when the outputs are LOW. Currently the inversion of the cog LED outputs is done with a `define but this can be handled by having a board specific wiring module that wires USER_LED[1:8] to ~cog_led[7:0] or something. That way, those who have a DE0 or DE2 board won't ever have to see code that's needed to invert the cog LED on the BeMicroCV's that they may not own. And of course the DIP switches make it possible to create other layouts where the LEDs are connected to the Propeller pins in one or more ways, instead of just being used as cog-running indicators.
===Jac
It's not that complex - netlists are simple ASCII files, and the scripts do what you could do with a pencil or magic marker.
If we look at Altium exports
http://techdocs.altium.com/display/ADOH/Netlist+Outputs
lots of choices, the simplest are wires based ones
I'll export 3 from LTSpice here and let's assume R1=FPGA and R2=Connector
WireList [00004] N001 R2 2 B Passive 10k R1 1 A Passive 10kAll 3 show R2.Pin2 wires to R1.Pin1
JMG
That's is just sweet. I assume you can elect "get all" somehow. That would allow you to use a scripting language to parse the pins and just look at a subset. Is the tcl scripting capable of parsing this kind of list... If not, I could do it on my Mac with Applescript.
Those were just examples of the expected Netlist formats.
It would need someone in Parallax to load the 123 PCB design, and then export NETLIST in some of those choices. (Easiest to just export all 3 ?)
As it appears WIRELIST can tag a Part-value attribute to each line (10k above), some simple editing of the 123 design file to make that attribute meaningful, would make parsing easier.
eg use a Connector naming convention that is easy to test for, and a clear FPGA name (U1?)
But I want to go one step further: I want to start using the DIP switches to switch pinouts. All the currently supported P1V target boards have at least 3 dip switches (the DE2-115 has no DIP switches but it has plenty of regular switches that can be used), which makes it possible to select 8 different configurations without the need to reflash the FPGA! You want to connect the SD card reader to the P1V? Want to use the on-board EEPROM? Connect the VGA output on the DE2-115? The Ethernet PHY on the BeMicroCV-A9? Just a matter of setting the DIP switches to select which P1V I/O signals are connected to which physical pins.
Now that's a very good idea