Xilinx ISE error - new to FPGA

[Raypfaff]

I've gone through some of the basic tutorials for writing in VHDL and I decided to play around with the open souce bitcoin miner.  Before the thread gets hijacked, yes I know I will make no money.  It's just a fun little project.  When I try to create a program using the ISE Webpack tool, I get the following warnings/errors.

 

NgdBuild:486 - Attribute "FACTORY_JF" is not allowed on symbol "dcm" of
   type "DCM_BASE".  This attribute will be ignored.
WARNING:NgdBuild:486 - Attribute "PHASE_SHIFT" is not allowed on symbol "dcm" of
   type "DCM_BASE".  This attribute will be ignored.
WARNING:NgdBuild:486 - Attribute "STARTUP_WAIT" is not allowed on symbol "dcm"
   of type "DCM_BASE".  This attribute will be ignored.
ERROR:NgdBuild:604 - logical block 'dcm' with type 'DCM_BASE' could not be
   resolved. A pin name misspelling can cause this, a missing edif or ngc file,
   case mismatch between the block name and the edif or ngc file name, or the
   misspelling of a type name. Symbol 'DCM_BASE' is not supported in target
   'spartan3e'.
 

There are, I think, several more warnings having to do with DCM_BASE.  I "think" that the problem is that DCM_BASE really needs to be DCM.  However, I can't find the definition of DCM_BASE in either the VHDL or in the .ucf file.  Does anyone have any idea what the problem here might actually be?

[alvieboy]

Perhaps it's using a generated IP from coregen.

 

Do you have anything like this in the project?

[Raypfaff]

I would have to see if I can verify that, but it doesn't look like it.  There doesn't seem to be an IP for DCM, unless it's embedded in something else I'm using.  If I recall DCM's just  a primitive.

[Rob]

I'm not sure if this will help or not, but I ran into a similar problem when I first started (not that long ago). My problem turned out to be that Xilinx dropped support for the sparten3e in ISE Webpack version 14.4,.  Installing ISE Webpack 14.3 solved my problem, maybe it will solve your problem too?

 

Alvie knows what he's doing though, I bet he can help if that doesn't work.

[Raypfaff]

Not that either.  I'm running 14.3  You can select Spartan 3E and the board as XC3S500E, so I assumed it supported the Papilio.  Thanks for telling me though, so I don't upgrade it.

[hamster]

DCM_BASE is a Vertex 5 / Spartan 6 primitive - Spartan 3E only supports the 'budget' version, the DCM_SP.

 

Check out http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_3/spartan3e_hdl.pdf for examples of the DCM_SP primitive - it should not be too hard to switch over.

 

If the DCM_BASE it is wrapped up in an IP coregen component and running "regenerate all cores" doesn't fix it then you may need to remove then recreate a component with the same function.

[alvieboy]

Raypfaff: can you provide a link to the source files you're using ?

 

Alvie

[Raypfaff]

Hamster, I'll give that a try.  I assumed that DCM_BASE wasn't correct, but the 3E does support DCM, so I assumed the name wasn't correct (since it says it's not supported in the 3E) and I was trying to figure out where it's coming from.

Alvieboy, for some reason I can't paste the link, but if you google "open source bitcoin miner", it's about 4 entries down.  The github link.

It's supposed to run on the Cyclone and Spartan, specifically the Spartan 6.

[alex]

I had a look at the source code you mentioned.

 

In your original post you didn't give enough info but you do mention you looked in the VHDL files, so the only VHDL files are in the /Projects/VHDL_* folders and since one is a Stratix, I assume you used the files in the VHDL_Xilinx_Port folder.

 

Now with the assumptions out of the way, there is a clear reference to DCM_BASE in top.vhd, line 97 and as hamster said this is a Virtex component (even Spartan 6 fails to compile that in).

 

Good news is that they are using that DCM_BASE in a very simple way, they just supply it with an input clock and reset signal and it just generates and output clock based on a multiplier and divisor. This means you can easily replace it with a DCM_SP. Given the settings they used, it is supplied with a 100MHz clock (you can tell from CLKIN_PERIOD => 10.0 where the 10 means nanoseconds) and the CLKFX_DIVIDE => 10 and CLKFX_MULTIPLY => 12 means they are producing 100*12/10 = 120MHz clock. You can get that from the Papilio 32MHz clock with a DCM_SP and a 15/4 ratio, basically at the very least the following code:

 

dcm : DCM_SPgeneric map (  CLKFX_DIVIDE => 4,  CLKFX_MULTIPLY => 15,  CLKIN_PERIOD => 31.25)port map (  CLKFX => clk_dcmout,  CLKIN => clk_dcmin,  RST => '0');

EDIT: just tried to synthesize it on a S6LX9 and it failed due to insufficient resources (too many slices required) so I doubt a S3E500 will work. You might have to set your sights on a less resource intensive project.

[Raypfaff]

Thanks very much for the help!  Sorry, I should have said I was using the Xilinx code in the projects folder.  I guess that I was using the IDE incorrectly.  I'm at work and it's not in front of me, but I tried using a "find all" command that I assumed would look in all the source code for the term "DCM_BASE".  I guess the command didn't work in the way I had interpreted it, as it came back with nothing found.

[neslekkim]

EDIT: just tried to synthesize it on a S6LX9 and it failed due to insufficient resources (too many slices required) so I doubt a S3E500 will work. You might have to set your sights on a less resource intensive project.

 

Does this mean that these small projects (well, they look small when looking at the code) actually requires very large amount of the fpga?, what is it in this code that need so much space?

 

And, have anyone gotten this to work on the Papilio Pro?

[ienliven]

The Serial version fits nicely on my nexys3 ( S06LX16 ), also runs on a Spartan 3E 500K.

 

https://github.com/teknohog/Xilinx-Serial-Miner

 

Peace.

[Raypfaff]

When I compile the serial miner, I get this.  Never seen this error before, so I'm not sure if it's something I messed up in the ucf file or this has something to do with the board itself.

 

Pack:1107 - Pack was unable to combine the symbols listed below into a

   single IOB component because the site type selected is not compatible. The

   component type is determined by the types of logic and the properties and

   configuration of the logic it contains. In this case an IO component of type

   IOB was chosen because the IO contains symbols and/or properties consistent

   with output or bi-directional usage and contains no other symbols or

   properties that require a more specific IO component type. Please double

   check that the types of logic elements and all of their relevant properties

   and configuration options are compatible with the physical site type of the

   constraint.

 

There are no symbols "below", just this error.

[Jack Gassett]

When I compile the serial miner, I get this.  Never seen this error before, so I'm not sure if it's something I messed up in the ucf file or this has something to do with the board itself.

 

Pack:1107 - Pack was unable to combine the symbols listed below into a

   single IOB component because the site type selected is not compatible. The

   component type is determined by the types of logic and the properties and

   configuration of the logic it contains. In this case an IO component of type

   IOB was chosen because the IO contains symbols and/or properties consistent

   with output or bi-directional usage and contains no other symbols or

   properties that require a more specific IO component type. Please double

   check that the types of logic elements and all of their relevant properties

   and configuration options are compatible with the physical site type of the

   constraint.

 

There are no symbols "below", just this error.

 

 

You need to look further up in your console for where the Error actually happens, this is a summary at the end of the console output that is saying something went wrong earlier.

 

Usually this error means that you are connecting an output to an input only pin or something. Make sure your rx and tx pins are connected the right way, I think the rx pin is connected to an input only pin and you will see this error if you try to connect tx to it.

 

Jack.

[Raypfaff]

Yeah, that appeared to fix it, but I'm not entirely sure why.  Here's my ucf.  I switched Tx and Rx from what the original mega wing logic board had,  The code compiles, but I haven't tried uploading it yet.

This is the ucf that I'm using,  I assume that the segments aren't quite right on it.

 

## Prohibit the automatic placement of pins that are connected to VCC or GND for configuration.

#CONFIG PROHIBIT=P99;

#CONFIG PROHIBIT=P43;

#CONFIG PROHIBIT=P42;

#CONFIG PROHIBIT=P39;

#CONFIG PROHIBIT=P49;

#CONFIG PROHIBIT=P48;

CONFIG PART=XC3S500E-VQ100-4;

 

NET "osc_clk" LOC = "P89";

 

# serial port receive & transmit

NET "RxD" LOC = "P88";

NET "TxD" LOC = "P90";

 

 

# 7 segment display, in the order that fpga4fun uses

NET "segment<7>" LOC = "P23";

NET "segment<6>" LOC = "P62";

NET "segment<5>" LOC = "P35";

NET "segment<4>" LOC = "P33";

NET "segment<3>" LOC = "P53";

NET "segment<2>" LOC = "P40";

NET "segment<1>" LOC = "P65";

NET "segment<0>" LOC = "P57";

 

NET "anode<0>" LOC = "P67";

NET "anode<1>" LOC = "P60";

NET "anode<2>" LOC = "P26";

NET "anode<3>" LOC = "P18";

 

#NET "led<7>" LOC = "R4";

#NET "led<6>" LOC = "F4";

#NET "led<5>" LOC = "P15";

#NET "led<4>" LOC = "E17";

#NET "led<3>" LOC = "K14";

#NET "led<2>" LOC = "K15";

#NET "led<1>" LOC = "J15";

#NET "led<0>" LOC = "J14";

 

 

 

[Jack Gassett]

It gets confusing when rx and tx is used. MOSI and MISO, like used in SPI prevents this confusion, but is not normally used for UARTs.

 

If you look at this screenshot of the rx/tx lines from the P1 IO schematic you see that USB_TXD is IP_L04P_0 and USB_RXD is IO_L05N_0. For USB_TX the IO pin starts with "IP" which means it is an input only pin. If it starts with "IO" like USB_TX then it is bidirectional IO. For the Papilio One USB_TXD is the only instance where an IP only pin was used, it was necessary because there was no full IO pins left over and that pin was always going to be an input for the FPGA.

 

In the schematic view USB_TXD (P88) and USB_RXD (P90) is from the USB chips point of view, so when we are speaking from the FPGA's point of view it is the opposite. FPGA_TXD is (P90) and FPGA_RXD is (P88).

 

In SPI terms the FPGA would be the master and the USB chip the slave so P90 would be MOSI (Master Out Slave In) and P88 would be MISO (Master In Slave Out).

 

The reference page shows SPI terminology which I always find useful to keep it straight in my head.

 

Another way to tell is to look at your top level VHDL file, look at the port definition for rx and tx, whichever one is defined as an input should be connected to the input only pin (P88 - MISO).

 

Jack.

[Raypfaff]

You are correct.  Swapping the rx/tx seems to make it work.  It took me a little while to check it, but the code seems to run.  I say "seems" bacause the chip gets a little hot and I'm assuming the default clock speed isn't correct.  It's not a fire danger, but I'm playing with FPGA bitcoin mining using an Cyclone IV chip I picked up for $15, so I wasn't willing to risk burning out  the Papilio.  I ran it for about 15 minutes, but it would be a miracle to get a nonce by that time.  However the miner.py code is communicating with the board. If anyone wants to continue playing with it, you'll need python installed plus the pyserial module and a jsonrpc module (just check out the readme contained in the project.)