In order to increase the speed of USB transfers and because there has been some instability with the UART communications between the OLS and the micro I'm working on integrating a SPI module into the VHDL code.
I'm attempting to use the following core at opencores.com because it seems to be the most popular SPI core.
http://opencores.com/project,spi (http://opencores.com/project,spi)
It's written in verilog and uses the wishbone bus as an interface which makes things a little more complicated then necessary but I don't really see any easier cores to use. If anyone has any recommendations on a simple but stable VHDL core they would be appreciated.
I've checked the first attempt to use the core into svn and it is synthesizing without errors. The next step is to update the micro firmware to move to SPI communications. The pin connections between the FPGA and the micro are:
## SPI
NET "ss" LOC = "P35" | IOSTANDARD = LVCMOS33 ;
NET "mosi" LOC = "P36" | IOSTANDARD = LVCMOS33 ;
NET "miso" LOC = "P38" | IOSTANDARD = LVCMOS33 ;
NET "sclk" LOC = "P40" | IOSTANDARD = LVCMOS33 ;
Will look into updating the firmware and testing tomorrow. As of right now the SPI core only echos the input back.
Jack.
I'm totally new to VHDL, FPGA, et alia. But I do have a question: The FPGA uses SPI to load initial settings from the Flash, right? Is that SPI hardware not available for reuse in the core?
We'll need to define a simple protocol using one additional pin. Since we're converting an async protocol, the PIC needs to signal the FPGA when new data is coming from the PC, and the FPGA needs to signal the PIC when it has data to send.
We should choose one device to be subservient, but most transactions won't happen at the same time. I think the only transactions that would logically occur simultaneously is if the FPGA started to dump a capture and the PC software sent the 5 x 0x00 cancel command.
I noticed the opencores site lists the SPI module as a master. The PIC and be either a master or slave module. Whichever way is easiest for you - there's enough room in the PIC to implement more advanced logic if we need it.
SS AUX2 RB1/RP4
MOSI AUX1 RB2/RP5
MISO CS RB3/RP6
SCLK AUX0 RB4/RP7
I'll kick together an outline for a new firmware and put it in the SVN.
I created a new folder for the SPI version of the firmware in SVN:
*updated hardware profile with new FPGA SPI pins
*added SPI master and slave setup functions that assign the peripherals to the right pins (the hard part)
*should be able to recycle the existing SPI send function as needed
I didn't add a control loop or anything yet because we need to flesh out the interaction a little more and choose if the PIC is master or slave.
To do:
*add slave receive/send (if needed)
*define IRQ pin for slave to alert of new async data (edit: this should be a shared PIC/ROM/FPGA pin probably)
*RX/TX control loop
The UART state machine could be moved from the FPGA to the PIC to maintain compatibility with SUMP. The SPI in FPGA can be setup as slave with simple commands altering the LA flags (RW flag + address, and value), and special multibyte command to readout the blocks/whole RAM.
This could be also used as framework for other project using the same HW :)
[quote author="rsdio"]
I'm totally new to VHDL, FPGA, et alia. But I do have a question: The FPGA uses SPI to load initial settings from the Flash, right? Is that SPI hardware not available for reuse in the core?
[/quote]
From what i understand the internal SPI cannot be used. But the SPI pins can be reused by the FPGA core loaded.
[quote author="robots"]The SPI in FPGA can be setup as slave with simple commands altering the LA flags (RW flag + address, and value), and special multibyte command to readout the blocks/whole RAM.
[/quote]
Does that mean I could control the capturing of data (setting speed/triggers etc.) from a SPI master?
Is it possible to route the SPI-signals to the wing-connector of the existing boards?
There are some really nice HID-to-(Master)SPI USB-devices available. For instance these here : http://www.codemercs.com/index.php?id=127&L=1 (http://http://www.codemercs.com/index.php?id=127&L=1)
Sounds like a perfect idea if we could update the FPGA-ROM on the Dataflash and capture data from the same application.
Very exiting
Eberhard
[quote author="wayoda"]
[quote author="robots"]The SPI in FPGA can be setup as slave with simple commands altering the LA flags (RW flag + address, and value), and special multibyte command to readout the blocks/whole RAM.
[/quote]
Does that mean I could control the capturing of data (setting speed/triggers etc.) from a SPI master?
Is it possible to route the SPI-signals to the wing-connector of the existing boards?
There are some really nice HID-to-(Master)SPI USB-devices available. For instance these here : http://www.codemercs.com/index.php?id=127&L=1 (http://http://www.codemercs.com/index.php?id=127&L=1)
Sounds like a perfect idea if we could update the FPGA-ROM on the Dataflash and capture data from the same application.
Very exiting
Eberhard
[/quote]
I was just presenting my idea of how it could be done :-/.
And yes the Dataflash can be used from the core (as some microblaze CPU cores do it). I don't think that you want to use the dataflash as storage for LA samples.
[quote author="jack.gassett"]
## SPI
NET "ss" LOC = "P35" | IOSTANDARD = LVCMOS33 ;
NET "mosi" LOC = "P36" | IOSTANDARD = LVCMOS33 ;
NET "miso" LOC = "P38" | IOSTANDARD = LVCMOS33 ;
NET "sclk" LOC = "P40" | IOSTANDARD = LVCMOS33 ;
[/quote]
I have just noticed that you are planing to use the AUXx pins as SPI.
Couldn't the SPI be shared with the ROM ? This would save 3 pins for further functions like RESET, INT (as Ian mentioned).
These are really straight and clean connections. My thought was to use these pins to get the max speed possible with the least amount of noise. At least one of the ROM SPI pins will need to be shard for an interrupt.
[quote author="ian"]
These are really straight and clean connections. My thought was to use these pins to get the max speed possible with the least amount of noise. At least one of the ROM SPI pins will need to be shard for an interrupt.
[/quote]
I still think that you are limited by the 12Mbit USB, so there is probably no point of going MAX speed, but rather clean design.
Ok, the specifications that I have configured on the FPGA are:
-FPGA is the master
-Clock is 100khz to start out, it is close to 115200 so makes it easier to start.
-lets use FPGA_AUX3 P34 on FPGA P21 on PIC as the DATA_READY line to signal data is ready from the slave.
-The SPI core can handle 32 bit or 4x32 transfers at a time. Not sure if this matters on PIC side.
-Lets stick with the pins already specified for development, we can switch to the shared SPI pins later but for now it is one less thing to go wrong.
I started writing a control loop and it got a bit complicated.
I think we probably need a read/write direction pin because we'll run into problem of not knowing when the data is actually coming out of the PIC, have little timing errors, etc.
100khz is fine, the PIC SPI slave is hardware based and will just 'go'.
The byte width doesn't matter much right now, as long as the PIC is just a middle-man between the SPI and USB.
Having the FPGA as master is not good idea. It might not be a problem when using slow speeds, but on higher speeds you might loose data.
Assuming usb interrupt highest possible priority, and that it takes quite a lot time to serve usb interrupt. There will be no time spare to serve the SPI interrupt and some data might get lost. This situation might never happen, due to the way Java client communicates with the OLS, but it might emerge some day later.
I have gotten to the same situation on one of my projects recently (but the problem might have been just me (: )
It will be much easier if the PIC is the SPI master, then there should be not need for a DATA_READY line. The PIC always initiates a connection and the FPGA always responds. There is never a situation where the FPGA initiates a communication. I didn't realize that until after I spent time integrating the SPI core that only acts as a master!
I guess it will be best to look for a SPI slave core.