09-02-2016, 03:26 PM
(This post was last modified: 09-02-2016, 03:28 PM by ppppenguin.)
When the documentation and reality disagree, reality is usually correct 
The PLD modules arrived today. The box was so light I wondered if it had anything in it all. It was dispatched last Thursday from Estonia so no complaints about delivery.
The PLD comes pre-programmed with a test build that works the LEDs and buttons. I hooked up power and the Xilinx programming probe, whacked in my own JEDEC file and saw some activity on the pins. Very slow activity. A simple brain fade meant I was running eveything about 1000 times slower than I intended. Easily fixed by changing the divider down from 25MHz to my main clock. I decided that about 25kHz was right for my main clock that runs button scan, LED scan and router controls. So I divide the onboard 25MHz osc by 1024. Here's the 10 bit counter.
process (CK25MHz) begin
if rising_edge(CK25MHz) then
CK25MHZ_DIVIDER <= CK25MHZ_DIVIDER + 1;
end if; -- CK25MHz
end process;
-- Assign main internal clock
CK <= CK25MHZ_DIVIDER(9);
Plug in the panel I wired yesterday and there are signs of life but it's all a bit gaga. Probe aorund the IO pins and it's definitely gaga. In a Xilinx design the pin allocations and properties are specified in a UCF file. It can be done in the VHDL but it's easier to have it in the UCF (The latest Xilinx tools have replaced the UCF with something else but that's not a problem here)
Example of an entry in the UCF, saying that bit 0 of the LED_COLUMN signal is assigned to pin A12 of the device. The # is the comment delimiter and the comment tells me it's connected to pin 3 of ribbon cable A.
NET "LED_COLUMN<0>" LOC = "A12"; # RIBBON_A<3>
The makers supply an example UCF and you would reasonably assume that device pin A12 is connected to their J3 pin 0.
net "io_j3<0>" loc = "A12" ;
J3 is one of the rows of IO pins and I'll forgive that what they call "0" is actually pin 2. So far so good. Except that my signals were all over the place. Their example UCF is all wrong. Comparing it against the supplied schematic then one or the other is very definitely riddled with errors. For now I'll assume the schematic is correct as it was done on a CAD system and it's a fair guess that they extracted a netlist from it to do the PCB layout. Hence the PCB and schematic stand a good chance of agreement. But you usually end up doing the UCF by hand, one of the less interesting jobs in the design process.
So I'll redo the UCF in accordance with the schematic and see if the signals appear in the right places. If they don't it will be a right royal PITA because the Xilinx is a BGA device and you can't see where the tracks go underneath it.

The PLD modules arrived today. The box was so light I wondered if it had anything in it all. It was dispatched last Thursday from Estonia so no complaints about delivery.
The PLD comes pre-programmed with a test build that works the LEDs and buttons. I hooked up power and the Xilinx programming probe, whacked in my own JEDEC file and saw some activity on the pins. Very slow activity. A simple brain fade meant I was running eveything about 1000 times slower than I intended. Easily fixed by changing the divider down from 25MHz to my main clock. I decided that about 25kHz was right for my main clock that runs button scan, LED scan and router controls. So I divide the onboard 25MHz osc by 1024. Here's the 10 bit counter.
process (CK25MHz) begin
if rising_edge(CK25MHz) then
CK25MHZ_DIVIDER <= CK25MHZ_DIVIDER + 1;
end if; -- CK25MHz
end process;
-- Assign main internal clock
CK <= CK25MHZ_DIVIDER(9);
Plug in the panel I wired yesterday and there are signs of life but it's all a bit gaga. Probe aorund the IO pins and it's definitely gaga. In a Xilinx design the pin allocations and properties are specified in a UCF file. It can be done in the VHDL but it's easier to have it in the UCF (The latest Xilinx tools have replaced the UCF with something else but that's not a problem here)
Example of an entry in the UCF, saying that bit 0 of the LED_COLUMN signal is assigned to pin A12 of the device. The # is the comment delimiter and the comment tells me it's connected to pin 3 of ribbon cable A.
NET "LED_COLUMN<0>" LOC = "A12"; # RIBBON_A<3>
The makers supply an example UCF and you would reasonably assume that device pin A12 is connected to their J3 pin 0.
net "io_j3<0>" loc = "A12" ;
J3 is one of the rows of IO pins and I'll forgive that what they call "0" is actually pin 2. So far so good. Except that my signals were all over the place. Their example UCF is all wrong. Comparing it against the supplied schematic then one or the other is very definitely riddled with errors. For now I'll assume the schematic is correct as it was done on a CAD system and it's a fair guess that they extracted a netlist from it to do the PCB layout. Hence the PCB and schematic stand a good chance of agreement. But you usually end up doing the UCF by hand, one of the less interesting jobs in the design process.
So I'll redo the UCF in accordance with the schematic and see if the signals appear in the right places. If they don't it will be a right royal PITA because the Xilinx is a BGA device and you can't see where the tracks go underneath it.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv







