SCK of flash on Basys3 (beginner question)

[bill maney]

I'm trying to talk to the flash on the basys3 to write my own data there.

The stock constraints file for basys3 has lines defining pins for CS and the data, but there are no lines for the SCK.   I tried adding this:

set_property PACKAGE_PIN C11 [get_ports QspiSCK]                    
set_property IOSTANDARD LVCMOS33 [get_ports QspiSCK]
 

based on a drawing in the basys3 data sheet but I get an error when I create the bitstream.

[DRC UCIO-1] Unconstrained Logical Port: 1 out of 21 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined.  To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.  Problem ports: QspiSCK.
 

There's probably a clue in the text of the constraints file at the beginning of the flash section that says "

#Note that CCLK_0 cannot be placed in 7 series devices. You can access it using the
#STARTUPE2 primitive.
 

I'd like to generate the SCK for the flash myself.  Is there a way to connect my logic to it?

[D@n]

@bill maney,

Yes, there's a way to do it, but you'll have to use the STARTUPE2 primitive.  Basically, that pin is "special", because it needs to be used to load the FPGA in the first place.  Since special hardware is connected to it, you can't connect to it through logic quite as easily as you might like.  That will also prevent you from using other I/O primitives on the pin like OSERDES, ODDR, etc. (they don't exist in the actual hardware for this pin).

Here's an example of what driving that pin through the STARTUPE2 primitive might look like.  You might find this example of a home-grown QSPI flash controller useful as well.

Dan

[bill maney]

Thanks for this suggestions.

I've added the following lines to my code:

STARTUPE2 #(
    .PROG_USR("FALSE"),    
    .SIM_CCLK_FREQ(10.0)
) STARTUPE2_inst (
    .CFGCLK     (/* NC */),
    .CFGMCLK    (/* NC */),
    .EOS        (/* NC */),
    .PREQ       (/* NC */),
    .CLK        (1'b0),
    .GSR        (1'b0),
    .GTS        (1'b0),
    .KEYCLEARB  (1'b0),
    .PACK       (1'b0),
    .USRCCLKO   (QspiSCK),
    .USRCCLKTS  (1'b0),
    .USRDONEO   (1'b0),
    .USRDONETS  (1'b1) 
);
 

This looks like progress. 

But without the PACKAGE_PIN and IOSTANDARD lines, the bitstream generation fails with " Unspecified I/O Standard"

If I include those lines to define the IO standard, it ignores the line because it says that C11 is not a pin.   I also tried CCLK_0 which gives the same thing.

I looked at the pinout for the XC7A35T-1CPG236C and it looks like CCLK_0 is connected to C11, so I think I'm stuck again.

 

 

 

[D@n]

@bill maney,

You shouldn't need to place CCLK_0 pin in your XDC file at all, neither should it be mentioned in the port list of your top level.  It's defined implicitly by the startup usage that already exists.

Dan

[bill maney]

If I don't have anything in the XDC, the bitstream fails because of the lack of an IO standard for the QspiSCK

What do you think I should do about defining the IO standard for the sck?

It suggested that I could use a command to disable the check for that pin, at the risk of damaging the board.   Do you think I should try that?

 

[D@n]

@bill maney,

If the bitstream generation is failing because of a lack of an I/O standard for the SCK pin, then you defined the SCK pin as a top level port in your design.  That's where the error needs to get fixed.

You don't need to risk damaging your board.  So, no, don't do that.

Fix your top level portlist instead.

Dan

[bill maney]

That worked.

I really appreciate your help on this.   I don't know where the world would be without guys like you kicking newbies over potential barriers.